Software Project Management-An overview

Software Project Management-An Overview
OPPORTUNITIES
1
―Software Project Management―
An overview
YOGENDRA SHRIVASTAVA
DPGD/OC12/0659
SPECIALIZATION: E-BUSINESS
WELINGKAR INSTITUTE OF MANAGEMENT DEVELOPMENT & RESEARCH
Year of Submission: September, 2014

OPPORTUNITIES
2

OPPORTUNITIES
3
ACKNOWLEDGEMENT
“Acknowledgement is an art, one can write glib stanzas without meaning a word, and on the
other hand one can make a simple expression of gratitude”
I take the opportunity to express my gratitude to all of them who in some or other way
helped me to accomplish this challenging project in Scania IT - Sweden. No amount
of written expression is sufficient to show my deepest sense of gratitude to them.
I am extremely thankful and pay my gratitude to my faculty guide Massih
Enayatollah (Maintenance Manager of Scania, SWDEN) for their valuable
guidance and support on completion of this project.
A special appreciative “Thank you” in accorded to all staff of L&T InfoTech,
Sweden for their positive support.
I also acknowledge with a deep sense of reverence, my gratitude towards my parents
and wife, who has always supported me morally.
At last but not least gratitude goes to all of my friends who directly or indirectly
helped me to complete this project report.

OPPORTUNITIES
4
Table of Contents
1. INTRODUCTION............................................................................................................6
2. PROJECT..........................................................................................................................7
2.1 Project Definition.......................................................................................................8
2.2 Project Attributes.......................................................................................................9
2.3 Project Constraint.......................................................................................................8
3. WHAT IS PROJECT MANAGEMENT.........................................................................10
3.1 Features of Project...................................................................................................12
3.2 Project Classification...............................................................................................13
3.3 Project Management tools and Techniques:.............................................................13
3.4 Project Success Factors:...........................................................................................14
3.5 Project Management Tools:......................................................................................15
4. PROJECT MANAGER...................................................................................................17
4.1. Role of a Project Manager.......................................................................................17
4.2. Responsibility of a Project Manager........................................................................17
4.3. Characteristics of a Project Manager.......................................................................19
4.4. Qualities of a Project Manager.................................................................................20
5. PROJECT LIFE CYCLE.................................................................................................23
5.1 Project Initiation.......................................................................................................24
5.2 Planning and design.................................................................................................25
5.3 Execution and Controlling.......................................................................................25
5.4 Closure.....................................................................................................................26
6. SOFTWARE DEVELOPMENT LIFE CYCLE..............................................................28
6.1 Benefit of SDLC......................................................................................................28
6.2 Phases of SDLC.......................................................................................................28
6.3 Project and Software Development Life.................................................................30
6.4 SDLC Models..........................................................................................................30
7. PROJECT WITH LEAN.................................................................................................44
7.1 LEAN SOFTWARE DEVELOPMENT..................................................................44
8. A STUDY IN PROJECT FAILURE...............................................................................49
CONCLUSION......................................................................................................................58
REFERENCES.......................................................................................................................59

OPPORTUNITIES
5
EXECUTIVE SUMMARY
Project Management developed from several fields of application including IT industry,
construction, engineering, and defence activity. Two forefathers of project management are
commonly known: Henry Gantt called the father of planning and control techniques who is
famous for his use of the Gantt chart as a project management tool; and Henri Fayol for his
creation of the five management functions which form the foundation of the body of knowledge
associated with project and program management. The 1950s marked the beginning of the
modern Project Management era. Project management became recognized as a distinct discipline
arising from the management discipline.
Today, in every organisation project management planning as an activity is necessary. It is an
important part of an organisation. And in software industry the ‘Software Project
management planning’ is a vital ingredient for the success of the organisation in the long run.
There are certain ways that are to be followed by every organisation, which ensures that it
has to systematically apply project management tools and techniques to complex projects, so
that organisation can achieve its planned objective.
Organizations increase their strategic capacity to deliver value by implementing management
innovations, defined as:
• Intentional change to organizational structure, management practices and decision making
systems/ knowledge, and managerial skills;
• Actions, processes, and behaviours new to the group or organization but not necessarily new to
the world (invention);
• Actions to improve an organization’s ability to function efficiently and effectively.

OPPORTUNITIES
6
1. INTRODUCTION
Here’s one way to describe software project management:
“The responsibility for producing a desired software result within acceptable limits of resource
usage.”
That probably covers everything, but it is difficult to connect with because it is such a general
statement. Here are some of the more specific aspects of this responsibility:
 Control of the development process. Project management is control of the development
process. But, even the simplest development methodologies are not simple and some (e.g.
Rational Unified Process) are rather complex. What kind of “control” of the development
process can be simple enough to understandable and practical?
 Means for achieving closure. Closure means “getting it done.” Just another way of
describing a successful project, but how many times have you heard a project manager or
developer say something like “it will be done when it’s done—don’t ask me to impose a
deadline or a firm budget on this project.” Closure is part of the game, and is a definite
obligation of project management.
 Achieving a cost-effective result. “Cost-effective” means the software works as desired,
provides the expected benefits and the cost in dollars and time is justified by the benefits.
Again, this is just another way of saying “get the desired result with acceptable resource
usage.”
So, how do we turn these ideas about “project management” into a practical, effective method of
management we can rely on for every project?
Eagle’s answer to this question begins with this definition:
Software project management is control of the transformation of requirements and resources into a
successful result.
To make this meaningful, we need to answer some questions in more detail. For instance:
 what kind of “control?”
 how do we understand “requirements” and “resources?”
 what is a “successful result?”
 what specific practices are both effective and practical?

OPPORTUNITIES
7
2. PROJECT
All of us have been involved in projects, whether they be our personal projects or in business and
industry. Examples of typical projects are for example:
Personal projects:
 obtaining an MCA degree
 writing a report
 planning a party
 planting a garden
Industrial projects:
 Construction of a building
 provide electricity to an industrial estate
 building a bridge
 designing a new airplane
Projects can be of any size and duration. They can be simple, like planning a party, or complex
like launching a space shuttle.
2.1 Project Definition:
A project can be defined in many ways:
A project is “a temporary endeavour undertaken to create a unique product, service, or result.”
Operations, on the other hand, is work done in organizations to sustain the business. Projects are
different from operations in that they end when their objectives have been reached or the project
has been terminated.
A project is temporary. A project‘s duration might be just one week or it might go on for years,
but every project has an end date. You might not know that end date when the project begins, but
it‘s there somewhere in the future. Projects are not the same as on-going operations, although the
two have a great deal in common.
A project is an endeavour. Resources, such as people and equipment, need to do work. The
endeavour is undertaken by a team or an organization, and therefore projects have a sense of
being intentional planned events. Successful projects do not happen spontaneously; some amount
of preparation and planning happens first.
Finally, every project creates a unique product or service. This is the deliverable for the project
and the reason, why that project was undertaken.

OPPORTUNITIES
8
2.2 Project Attributes:
Projects come in all shapes and sizes. The following attributes help us to define a project further:
- A project has a unique purpose. Every project should have a well-defined objective. For example,
many people hire firms to design and build a new house, but each house, like each person, is
unique.
- A project is temporary. A project has a definite beginning and a definite end. For a home
construction project, owners usually have a date in mind when they‘d like to move into their new
homes.
- A project is developed using progressive elaboration or in an iterative fashion.
Projects are often defined broadly when they begin, and as time passes, the specific details of the
project become clearer. For example, there are many decisions that must be made in planning and
building a new house. It works best to draft preliminary plans for owners to approve before more
detailed plans are developed.
- A project requires resources, often from various areas.
Resources include people, hardware, software, or other assets. Many different types of people, skill
sets, and resources are needed to build a home.
- A project should have a primary customer or sponsor. Most projects have many interested parties
or stakeholders, but someone must take the primary role of sponsorship. The project sponsor
usually provides the direction and funding for the project.
- A project involves uncertainty. Because every project is unique, it is sometimes difficult to define
the project‘s objectives clearly, estimate exactly how long it will take to complete, or determine
how much it will cost. External factors also cause uncertainty, such as a supplier going out of
business or a project team member needing unplanned time off. This uncertainty is one of the main
reasons project management is so challenging.

OPPORTUNITIES
9
2.3 Project Constraint:
Like any human undertaking, projects need to be performed and delivered under certain
constraints. Traditionally, these constraints have been listed as scope, time, and cost. These are
also referred to as the Project Management Triangle, where each side represents a constraint. One
side of the triangle cannot be changed without impacting the others. A further refinement of the
constraints separates product 'quality' or 'performance' from scope, and turns quality into a fourth
constraint.
The time constraint refers to the amount of time available to complete a project. The cost
constraint refers to the budgeted amount available for the project. The scope constraint refers to
what must be done to produce the project's end result. These three constraints are often
competing constraints: increased scope typically means increased time and increased cost, a tight
time constraint could mean increased costs and reduced scope, and a tight budget could mean
increased time and reduced scope.
The discipline of project management is about providing the tools and techniques that enable the
project team (not just the project manager) to organize their work to meet these constraints.
Another approach to project management is to consider the three constraints as finance, time and
human resources. If you need to finish a job in a shorter time, you can allocate more people at the
problem, which in turn will raise the cost of the project, unless by doing this task quicker we will
reduce costs elsewhere in the
project by an equal amount.
2.3.1 Time:
For analytical purposes, the time required to produce a product or service is estimated using
several techniques. One method is to identify tasks needed to produce the deliverables
documented in a work breakdown structure or WBS. The work effort for each task is estimated
and those estimates are rolled up
into the final deliverable estimate.
The tasks are also prioritized, dependencies between tasks are identified, and this information is
documented in a project schedule. The dependencies between the tasks can affect the length of
the overall project (dependency constraint), as can the
availability of resources (resource constraint). Time is not considered a cost nor a resource since
the project manager cannot control the rate at which it is expended. This makes it different from
all other resources and cost categories.
2.3.2 Cost:
Cost to develop a project depends on several variables including : labour rates, material rates, risk
management, plant (buildings, machines, etc.), equipment, and profit. When hiring an
independent consultant for a project, cost will typically be
determined by the consultant's or firms per diem rate multiplied by an estimated quantity for
completion.

OPPORTUNITIES
10
Figure 1.1: The Project management Triangle
2.3.3 Scope:
Scope is requirement specified for the end result. The overall definition of what the project is
supposed to accomplish, and a specific description of what the end result should be or accomplish
can be said to be the scope of the project. A major component of scope is the quality of the final
product. The amount of time put into
individual tasks determines the overall quality of the project. Some tasks may require a given
amount of time to complete adequately, but given more time could be completed exceptionally.
Over the course of a large project, quality can have a significant impact on time and cost or vice
versa.
Together, these three constraints viz. Scope, Schedule & Resources have given rise to the phrase
"On Time, On Spec, On Budget". In this case, the term "scope" is substituted with
“spec(ification)"

OPPORTUNITIES
11
3. WHAT IS PROJECT MANAGEMENT
Project management is “the application of knowledge, skills, tools and techniques to project
activities to meet the project requirements.” The effectiveness of project management is critical
in assuring the success of any substantial activity. Areas of responsibility for the person handling
the project include planning, control and implementation. A project should be initiated with a
feasibility study, where a clear definition of the goals and ultimate benefits need to be
determined. Senior managers' support for projects is important so as to ensure authority and
direction throughout the project's progress and, also to ensure that the goals of the organization
are effectively achieved in this process.
Knowledge, skills, goals and personalities are the factors that need to be considered within
project management. The project manager and his/her team should collectively possess the
necessary and requisite interpersonal and technical skills to facilitate control over the various
activities within the project.
What is a Management?
The process of dealing with or controlling things or people.

OPPORTUNITIES
12
Project Management?
Project management is the process and activity of planning, organizing, motivating, and
controlling resources, procedures and protocols to achieve specific goals in scientific or daily
problems.
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.
3.1 Features of projects
• Projects are often carried out by a team of people who have been assembled for that
specific purpose. The activities of this team may be co-ordinated by a project manager.
• Project teams may consist of people from different backgrounds and different parts of

OPPORTUNITIES
13
the organisation. In some cases project teams may consist of people from different
organisations.
• Project teams may be inter-disciplinary groups and are likely to lie outside the normal
organisation hierarchies.
• The project team will be responsible for delivery of the project end product to some
sponsor within or outside the organisation. The full benefit of any project will not
become available until the project has been completed.
3.2 Project Classification:
In recent years more and more activities have been tackled on a project basis. Project teams and a
project management approach have become common in most organisations. The basic approaches
to project management remain the same regardless of the type of project being considered. You
may find it useful to consider projects in relation to a number of major classifications:
a) Engineering and construction
The projects are concerned with producing a clear physical output, such as roads, bridges or
buildings. The requirements of a project team are well defined in terms of skills and
background, as are the main procedures that have to be undergone. Most of the problems which
may confront the project team are likely to have occurred before and therefore their solution may
be based upon past experiences.
b) Introduction of new systems
These projects would include computerisation projects and the introduction of new systems and
procedures including financial systems. The nature and constitution of a project team may
vary with the subject of the project, as different skills may be required and different end-users may
be involved. Major projects involving a systems analysis approach may incorporate clearly
defined procedures within an organisation.
c) Responding to deadlines and change
An example of responding to a deadline is the preparation of an annual report by a specified date.
An increasing number of projects are concerned with designing organisational or environmental
changes, involving developing new products and services.
3.3 Project Management Tools and Techniques:
In Project planning is at the heart of project management. One can't manage and control project
activities if there is no plan. Without a plan, it is impossible to know if the correct activities are
underway, if the available resources are adequate or of the project can be completed within the
desired time. The plan becomes the roadmap that the project team members use to guide them
through the project activities. Project management tools and techniques assist project managers
and their teams in carrying out work in all nine knowledge areas. For example, some popular time-
management tools and techniques include Gantt charts, project network diagrams, and critical path
analysis. Table 1.1 lists some commonly used tools and techniques by knowledge area.

OPPORTUNITIES
14
Knowledge Area Tools & Techniques
Integration Project selection methods, project management
Management methodologies, stakeholder analyses,
project charters, project management
plans, project management software,
change requests, change control boards,
project review meetings, lessons-learned
Reports.
Scope management Scope statements, work breakdown structures,
mind maps, statements of work, Requirements
analyses, scope management plans,
scope verification techniques, and scope
change controls.
Cost Management Net present value, return on investment, Payback
analyses, earned value management,
project portfolio management, cost
estimates, cost management plans, cost
Baselines
Time management Gantt charts, project network diagrams,
critical-path analyses, crashing, fast
tracking, schedule
performance measurements
Human resource Motivation techniques, empathic listening,
management responsibility assignment matrices, projects
organizational charts, resource histograms, team
building exercises
Quality management Quality metrics, checklists, quality control charts,
Pareto diagrams, fishbone diagrams,
maturity models, statistical methods
Table 1.1: Project Management Tools and Techniques
3.4 Project Success Factors:
In The successful design, development, and implementation of information technology (IT)
projects is a very difficult and complex process. However, although developing IT projects can be
difficult, the reality is that a relatively small number of factors control the success or failure of
every IT project, regardless of its size or complexity. The problem is not that the factors are
unknown; it is that they seldom form an integral part of the IT development process. Some of the
factors that influence projects and may help them succeed are
- Executive Support
- User involvement
- Experienced project managers

OPPORTUNITIES
15
- Limited scope
- Clear basic requirements
- Formal methodology
- Reliable estimates
3.5 Project Management Tools:
Delivering a project amidst competing priorities and organizational chaos requires experience,
skills, and a sound toolkit. An effective project manager recognizes when a given tool is needed,
and applies the tool effectively for the project’s benefit. Knowing the tools at your disposal will
help you move your project forward and organize the chaos around you.
Very few people are excellent project managers, because project management is an increasingly
complex discipline. For this reason, successful project managers are in high demand globally, and
financial rewards and prestige go hand in hand with successful project management.
This explains the various tools used in project management and provides links to some of the best
working documents (templates, forms, guides, etc.) on the web.
Tools:
Charter –
The Project Charter is typically a one page document that provides a snapshot of the project,
including goals, business benefits, schedule, and required resources. The Project Charter is
commonly used as an approval document, giving a project manager authority to launch the
project. Also see our project charter template page for an Excel® template and instructions.
phases of project management
Critical Path Method –
The critical path method organizes project activities and links them together based on their
dependencies to one another. The end result is a complete project timeline and list of the vital few
activities that determine that timeline.
Gantt Chart –
A Gantt Chart is a visual project scheduling tool that uses a horizontal bar chart to show major
project activities, planned vs. actual start and finish dates, and in some cases dependent activities
(i.e. one activity cannot start before another is completed). See the Gantt Chart Excel page for a
template and instructions.
Project Closing Report –
The project closing report summarizes project results and lessons learned, and can also serve as
the formal project close-out when presented in a final meeting with project stakeholders.
Project Milestone Checklist –
The milestone checklist shows the major milestones in a project, their priority, and current status.
Other columns can be added as well, such as planned/actual completion dates.
Project Management Plan –

OPPORTUNITIES
16
A project management plan is a comprehensive document that includes such things as the charter,
major deliverables, schedule, project budget, risk assessments, and roles and responsibilities.
Request for Proposal (RFP) –
Projects often outsource some or all of the actual work that will deliver the end result. In these
cases, a Request for Proposal will ensure that outside contractors provide a consistent
proposal/quotation package.
Responsibility Matrix –
A responsibility matrix, also known as a RACI chart (Responsible, Accountable, Consulted,
Informed), is a great tool for documenting roles and responsibilities for cross-functional teams.
Risk Management Plan –
The Risk Management Plan lists project risks, their potential impact, and associated
countermeasures.
There are various other popular tools in market which fulfil various purposes.
i.e.
Deployment type:
• Web-Based
• Installed
Features:
• Budget Management
• Bug Tracking
• Collaboration
• Email Integration
• File Sharing
• Gantt Charts
• Idea Management
• Issue Management
• Milestone Tracking
• Percent-Complete Tracking
• Portfolio Management
• Project Planning
• Requirements Management
• Resource Management
• Status Tracking
• Task Management
• Testing / QA Management
• Time & Expense Tracking

OPPORTUNITIES
17
4. PROJECT MANAGER
4.1 Role of a Project Manager:
The project manager is the driving force in the management
control loop. This individual seldom participates directly in the
activities that produce the end result, but rather strives to maintain the
progress and productive mutual interaction of various parties in such a
way that overall risk of failure is reduced.
A project manager is often a client representative and has to
determine and implement the exact needs of the client, based on
knowledge of the firm he/she is representing. The ability to adapt to the
various internal procedures of the contracting party, and to form close
links with the nominated representatives, is essential in ensuring that the
key issues of cost, time, quality, and above all, client satisfaction, can
be realized.
In whatever field, a successful project manager must be able to
envisage the entire project from start to finish and to have the ability to
ensure that this vision is realized.
When they are appointed, project managers should be given terms of
reference that define their:
• Objectives;
• Responsibilities;
• Limits of authority.
4.2 Responsibility of a Project Manager:
The objective of every project manager is to deliver the product on
time, within budget and with the required quality. Although the precise
responsibilities of a project manager will vary from company to company
and from project to project, they should always include planning and
forecasting. Three additional areas of management responsibility are:
 Interpersonal responsibilities, which include:
- Leading the project team;
- Liaising with initiators, senior management and suppliers;
- Being the 'figurehead', i.e. setting the example to the project team
and representing the project on formal occasions.
 Informational responsibilities, which include:

OPPORTUNITIES
18
- Monitoring the performance of staff and the implementation of the
project plan;
- Disseminating information about tasks to the project team;
- Disseminating information about project status to initiators and
senior management;
- Acting as the spokesman for the project team.
 Decisional responsibilities, which include:
- Allocating resources according to the project plan, and adjusting
those allocations when circumstances dictate (i.e. the project
manager has responsibility for the budget);
- Negotiating with the initiator about the optimum interpretation of
contractual obligations, with the company management for
resources, and with project staff about their tasks;
- Handling disturbances to the smooth progress of the project such
as equipment failures and personnel problems.
Does IT Project Management is an easy job?
IT Project Management is not an easy job. See.

OPPORTUNITIES
19
4.3 Characteristics of a Project Manager:
Good project managers are hard enough to find, and great project
managers are rarer still. We now have a peek inside the top 2 percent of
project managers, based on a study of 860 of them as rated by their
peers/clients. Not surprisingly, great project management requires a lot
more than the ability to move a milestone.
Here are the top 10 Characteristics of project managers who are really
making ideas happen:
1. Command authority naturally.
In other words, they don’t need borrowed power to enlist the help of
others – they just know how to do it. They are optimistic leaders who are
viewed in a favourable light and are valued by the organization.
2. Possess quick sifting abilities, knowing what to note and what to
ignore.
The latter is more important since there’s almost always too much data,
and rarely too little. Ignoring the right things is better than trying to master
extraneous data.
3. Set, observe, and re-evaluate project priorities frequently.
They focus and prioritize by handling fewer emails, attending fewer
meetings, and generally limiting their data input.
4. Ask good questions and listen to stakeholders.
Great project managers don’t just go through the motions. They care about
communication and the opinions of the parties involved. They are also
sufficiently self-aware to know how their communication is received by
those stakeholders.
5. Do not use information as a weapon or a means of control.
They communicate clearly, completely, and concisely. All the while
giving others real information without fear of what they’ll do with it.
6. Adhere to predictable communication schedules
Recognizing that it’s the only deliverable early in a project cycle. All this
takes place after very thorough pre-execution planning to eliminate as
many variables as possible.
7. Possess domain expertise in project management as applied to a
particular field.
It’s not just that they have generic project management skills; they have a
deep familiarity with one or multiple fields that gives them a natural
authority and solid strategic insight.
8. Exercise independent and fair consensus-building skills when
conflict arises.

OPPORTUNITIES
20
But they embrace only as much conflict as is absolutely necessary, neither
avoiding nor seeking grounds for control of a particular project segment.
9. Cultivate and rely on extensive informal networks inside and
outside the firm to solve problems that arise.
They identify any critical issues that threaten projects and handle them
resolutely (vs. ignoring them).
10. Look forward to going to work!
They believe that project management is an exciting challenge that’s
critical to success. The truly great ones view project management as a
career and not a job, and they treat it like so by seeking additional training
and education.
In summary, great project managers plan, manage, and handle details in a
way that lets others relax.
4.4 Qualities of a Project Manager:
What qualities are most important for a project leader to be effective?
Over the past few years, the people at ESI International, world leaders in
Project Management Training, have looked in to what makes an effective
project leader. With the unique opportunity to ask some of the most
talented project leaders in the world on their Project Leadership courses
ESI have managed to collect a running tally on their responses. Below are
the top 10 in rank order according to frequency listed.
1. Inspires a Shared Vision
An effective project leader is often described as having a vision of where
to go and the ability to articulate it. Visionaries thrive on change and being
able to draw new boundaries. It was once said that a leader is someone
who "lifts us up, gives us a reason for being and gives the vision and spirit
to change." Visionary leaders enable people to feel they have a real stake
in the project. They empower people to experience the vision on their
own. According to Bennis "They offer people opportunities to create their
own vision, to explore what the vision will mean to their jobs and lives,
and to envision their future as part of the vision for the organisation."
(Bennis, 1997)
2. Good Communicator
The ability to communicate with people at all levels is almost always
named as the second most important skill by project managers and team
members. Project leadership calls for clear communication about goals,
responsibility, performance, expectations and feedback.
There is a great deal of value placed on openness and directness. The
project leader is also the team's link to the larger organisation. The leader
must have the ability to effectively negotiate and use persuasion when
necessary to ensure the success of the team and project. Through effective

OPPORTUNITIES
21
communication, project leaders support individual and team achievements
by creating explicit guidelines for accomplishing results and for the career
advancement of team members.
3. Integrity
One of the most important things a project leader must remember is that
his or her actions, and not words, set the modus operandi for the team.
Good leadership demands commitment to, and demonstration of, ethical
practices. Creating standards for ethical behaviour for oneself and living
by these standards, as well as rewarding those who exemplify these
practices, are responsibilities of project leaders. Leadership motivated by
self-interest does not serve the well being of the team. Leadership based
on integrity represents nothing less than a set of values others share,
behaviour consistent with values and dedication to honesty with self and
team members. In other words the leader "walks the talk" and in the
process earns trust.
4. Enthusiasm
Plain and simple, we don't like leaders who are negative - they bring us
down. We want leaders with enthusiasm, with a bounce in their step, with
a can-do attitude. We want to believe that we are part of an invigorating
journey - we want to feel alive. We tend to follow people with a can-do
attitude, not those who give us 200 reasons why something can't be done.
Enthusiastic leaders are committed to their goals and express this
commitment through optimism. Leadership emerges as someone expresses
such confident commitment to a project that others want to share his or her
optimistic expectations. Enthusiasm is contagious and effective leaders
know it.
5. Empathy
What is the difference between empathy and sympathy? Although the
words are similar, they are, in fact, mutually exclusive. According to
Norman Paul, in sympathy the subject is principally absorbed in his or her
own feelings as they are projected into the object and has little concern for
the reality and validity of the object's special experience. Empathy, on the
other hand, presupposes the existence of the object as a separate
individual, entitled to his or her own feelings, ideas and emotional history
(Paul, 1970). As one student so eloquently put it, "It's nice when a project
leader acknowledges that we all have a life outside of work."
6. Competence
Simply put, to enlist in another's cause, we must believe that that person
knows what he or she is doing. Leadership competence does not however
necessarily refer to the project leader's technical abilities in the core
technology of the business. As project management continues to be
recognised as a field in and of itself, project leaders will be chosen based
on their ability to successfully lead others rather than on technical
expertise, as in the past. Having a winning track record is the surest way to
be considered competent. Expertise in leadership skills is another

OPPORTUNITIES
22
dimension in competence. The ability to challenge, inspire, enable, model
and encourage must be demonstrated if leaders are to be seen as capable
and competent.
9. Ability to Delegate Tasks
Trust is an essential element in the relationship of a project leader and his
or her team. You demonstrate your trust in others through your actions -
how much you check and control their work, how much you delegate and
how much you allow people to participate. Individuals who are unable to
trust other people often fail as leaders and forever remain little more that
micro-managers, or end up doing all of the work themselves. As one
project management student put it, "A good leader is a little lazy." An
interesting perspective!
10. Cool Under Pressure
In a perfect world, projects would be delivered on time, under budget and
with no major problems or obstacles to overcome. But we don't live in a
perfect world - projects have problems. A leader with a hardy attitude will
take these problems in stride. When leaders encounter a stressful event,
they consider it interesting, they feel they can influence the outcome and
they see it as an opportunity. "Out of the uncertainty and chaos of change,
leaders rise up and articulate a new image of the future that pulls the
project together." (Bennis 1997) And remember - never let them see you
sweat.
11. Team-Building Skills
A team builder can best be defined as a strong person who provides the
substance that holds the team together in common purpose toward the
right objective. In order for a team to progress from a group of strangers to
a single cohesive unit, the leader must understand the process and
dynamics required for this transformation. He or she must also know the
appropriate leadership style to use during each stage of team development.
The leader must also have an understanding of the different team players
styles and how to capitalise on each at the proper time, for the problem at
hand.
12. Problem Solving Skills
Although an effective leader is said to share problem-solving
responsibilities with the team, we expect our project leaders to have
excellent problem-solving skills themselves. They have a "fresh, creative
response to here-and-now opportunities," and not much concern with how
others have performed them. (Kouzes 1987)

OPPORTUNITIES
23
5. PROJECT LIFE CYCLE
The Project Life Cycle refers to a logical sequence of activities to
accomplish the project’s goals or objectives. Regardless of scope or
complexity, any project goes through a series of stages during its life.
There is first an Initiation or Starting phase, in which the outputs and
critical success factors are defined, followed by a Planning phase,
characterized by breaking down the project into smaller parts/tasks, an
Execution phase, in which the project plan is executed, and lastly a
Closure or Exit phase, that marks the completion of the project. Project
activities must be grouped into phases because by doing so, the project
manager and the core team can efficiently plan and organize resources for
each activity, and also objectively measure achievement of goals and
justify their decisions to move ahead, correct, or terminate. It is of great
importance to organize project phases into industry-specific project cycles.
Why? Not only because each industry sector involves specific
requirements, tasks, and procedures when it comes to projects, but also
because different industry sectors have different needs for life cycle
management methodology. And paying close attention to such details is
the difference between doing things well and excelling as project
managers.
Diverse project management tools and methodologies prevail in
the different project cycle phases. Let‘s take a closer look at what‘s
important in each one of these stages:
5.1 Project Initiation:
The initiation stage determines the nature and scope of the
development. If this stage is not performed well, it is unlikely that the
project will be successful in meeting the business‘s needs. The key project
controls needed here are an understanding of the business environment
and making sure that all necessary controls are incorporated into the
project. Any deficiencies should be reported and a recommendation should

OPPORTUNITIES
24
be made to fix them.
The initiation stage should include a plan that encompasses the following
areas:
• Analysing the business needs/requirements in measurable goals.
• Reviewing of the current operations.
• Conceptual design of the operation of the final product.
• Equipment and contracting requirements including an assessment
of long lead time items.
• Financial analysis of the costs and benefits including a budget.
• Stakeholder analysis, including users, and support personnel for
the project.
• Project charter including costs, tasks, deliverables, and schedule.
5.2 Planning and Design:
After the initiation stage, the system is designed. Occasionally, a
small prototype of the final product is built and tested. Testing is generally
performed by a combination of testers and end users, and can occur after
the prototype is built or concurrently. Controls should be in place that
ensures that the final product will meet the specifications of the project
charter. The results of the design stage should include a product design
that:
• Satisfies the project sponsor (the person who is providing the
project budget), end user, and business requirements.
• Functions as it was intended.
• Can be produced within acceptable quality standards.
• Can be produced within time and budget constraints.
5.3 Execution & Controlling:
Monitoring and Controlling consists of those processes performed
to observe project execution so that potential problems can be identified in
a timely manner and corrective action can be taken, when necessary, to
control the execution of the project. The key benefit is that project
performance is observed and measured regularly to identify variances
from the project management plan.

OPPORTUNITIES
25
Monitoring and Controlling includes:
• Measuring the on-going project activities (where we are);
• Monitoring the project variables (cost, effort, scope, etc.) against
the project management plan and the project performance baseline
(where we should be);
• Identify corrective actions to address issues and risks properly
(How can we get on track again);
• Influencing the factors that could circumvent integrated change
control so only approved changes are implemented
In multi-phase projects, the Monitoring and Controlling process
also provides feedback between project phases, in order to implement
corrective or preventive actions to bring the project into compliance with
the project management plan.
Project Maintenance is an on-going process, and it includes:
• Continuing support of end users
• Correction of errors
• Updates of the software over time
In this stage, auditors should pay attention to how effectively and
quickly user problems are resolved.
Over the course of any IT project, the work scope may change.
Change is normal and expected part of the process. Changes can be the
result of necessary design modifications, differing site conditions, material
availability, client-requested changes, value engineering and impacts from
third parties, to name a few. Beyond executing the change in the field, the
change normally needs to be documented to show what was actually
developed. This is referred to as Change Management. Hence, the owner
usually requires a final record to show all changes or, more specifically,
any change that modifies the tangible portions of the finished work. The
record is made on the contract documents – usually, but not necessarily
limited to, the design drawings. The end product of this effort is what the
industry terms as-built drawings, or more simply, “as built”.
When changes are introduced to the project, the viability of the
project has to be re-assessed. It is important not to lose sight of the initial
goals and targets of the projects. When the changes accumulate, the
forecasted result may not justify the original proposed investment in the
project.
5.4 Closure:

OPPORTUNITIES
26
Closing includes the formal acceptance of the project and the
ending thereof. Administrative activities include the archiving of the files
and documenting lessons learned.
This phase consists of:
• Project close: Finalize all activities across all of the process
groups to formally close the project or a project phase.
• Contract closure: Complete and settle each contract (including the
resolution of any open items) and close each contract applicable to
the project or project phase.

Software Project Management – An Overview 27
6. SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
SDLC stands for Software Development Life Cycle. A Software Development Life Cycle is
essentially a series of steps, or phases, that provide a model for the development and
lifecycle management of an application or piece of software. The methodology within the
SDLC process can vary across industries and organizations, but standards such as ISO/IEC
12207 represent processes that establish a lifecycle for software, and provide a mode for the
development, acquisition, and configuration of software systems.
6.1 Benefit of SDLC:
The intent of a SDLC process it to help produce a product that is cost-efficient, effective,
and of high quality. Once an application is created, the SDLC maps the proper deployment
and decommissioning of the software once it becomes a legacy. The SDLC methodology
usually contains the following stages: Analysis (requirements and design), construction,
testing, release, and maintenance (response). Veracode makes it possible to integrate
automated security testing into the SDLC process through use of its cloud based platform.
6.2 Phases of SDLC:
There are various software development approaches defined and designed which are
used/employed during development process of software, these approaches are also referred
as “Software Development Process Models” (e.g. Waterfall model, incremental model, V-
model, iterative model, etc.). Each process model follows a particular life cycle in order to
ensure success in process of software development.
Software life cycle models describe phases of the software cycle and the order in which
those phases are executed. Each phase produces deliverables required by the next phase in
the life cycle. Requirements are translated into design. Code is produced according to the

design which is called development phase. After coding and development the testing
verifies the deliverable of the implementation phase against requirements.
There are mainly six phases in every Software development life cycle model:
1) Requirement gathering and analysis
2) Design
3) Implementation or coding
4) Testing
5) Deployment
6) Maintenance
1) Requirement gathering and analysis:
Business requirements are gathered in this phase. This phase is the main focus of the
project managers and stake holders. Meetings with managers, stake holders and users are
held in order to determine the requirements like; Who is going to use the system? How will
they use the system? What data should be input into the system? What data should be
output by the system? These are general questions that get answered during a requirements
gathering phase. After requirement gathering these requirements are analyzed for their
validity and the possibility of incorporating the requirements in the system to be
development is also studied.
Finally, a Requirement Specification document is created which serves the purpose of
guideline for the next phase of the model.
2) Design:
In this phase the system and software design is prepared from the requirement
specifications which were studied in the first phase. System Design helps in specifying
hardware and system requirements and also helps in defining overall system architecture.
The system design specifications serve as input for the next phase of the model.
3) Implementation / Coding:
On receiving system design documents, the work is divided in modules/units and actual
coding is started. Since, in this phase the code is produced so it is the main focus for the
developer. This is the longest phase of the software development life cycle.
4) Testing:
After the code is developed it is tested against the requirements to make sure that the
product is actually solving the needs addressed and gathered during the requirements phase.
During this phase unit testing, integration testing, system testing, acceptance testing are
done.
5) Deployment:
After successful testing the product is delivered / deployed to the customer for their use.

6) Maintenance:
Once when the customers starts using the developed system then the actual problems
comes up and needs to be solved from time to time. This process where the care is taken for
the developed product is known as maintenance.
Project and Software Development Life Cycle:
6.3 SDLC Models:
There are various software development life cycle models defined and designed which are
followed during software development process. These models are also referred as
"Software Development Process Models".
Each process model follows a Series of steps unique to its type, in order to ensure success
in process of software development. Following are the most
important and popular SDLC models followed in the industry:
 Waterfall Model
 Iterative Model
 Spiral Model
 V-Model
 Big Bang Model
 Agile Model
The other related methodologies are Agile Model, RAD Model – Rapid Application

Development and Prototyping Models.
Waterfall Model
The Waterfall Model was first Process Model to be introduced. It is also referred to as a
linear-sequential life cycle model. It is very simple to understand and use. In a
waterfall model, each phase must be completed before the next phase can begin and there is
no overlapping in the phases.
Waterfall model is the earliest SDLC approach that was used for software development
.The waterfall Model illustrates the software development process in a linear sequential
flow; hence it is also referred to as a linear-sequential life cycle model. This means that any
phase in the development process begins only if the previous phase is complete. In
waterfall model phases do not overlap.
Waterfall Model design
Waterfall approach was first SDLC Model to be used widely in Software Engineering to
ensure success of the project. In "The Waterfall" approach, the whole process of software
development is divided into separate phases. In Waterfall model, typically, the outcome of
one phase acts as the input for the next phase sequentially.
Following is a diagrammatic representation of different phases of waterfall model.
The sequential phases in Waterfall model are:
 Requirement Gathering and analysis:
All possible requirements of the system to be developed are captured in this phase and
documented in a requirement specification doc.
 System Design:
The requirement specifications from first phase are studied in this phase and system design
is prepared. System Design helps in specifying hardware and system requirements and also
helps in defining overall system architecture.

 Implementation:
With inputs from system design, the system is first developed in small programs called
units, which are integrated in the next phase. Each unit is developed and tested for its
functionality which is referred to as Unit Testing.
 Integration and Testing:
All the units developed in the implementation phase are integrated into a system after
testing of each unit. Post integration the entire system is tested for any faults and failures.
 Deployment of system:
Once the functional and non functional testing is done, the product is deployed in the
customer environment or released into the market.
 Maintenance:
There are some issues which come up in the client environment. To fix those issues patches
are released. Also to enhance the product some better versions are released. Maintenance is
done to deliver these changes in the customer environment.
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the
defined set of goals are achieved for previous phase and it is signed off, so the name
"Waterfall Model". In this model phases do not overlap.
Waterfall Model Application
Every software developed is different and requires a suitable SDLC approach to be
followed based on the internal and external factors. Some situations where the use of
Waterfall model is most appropriate are:
 Requirements are very well documented, clear and fixed
 Product definition is stable
 Technology is understood and is not dynamic
 There are no ambiguous requirements
 Ample resources with required expertise are available to support the product
 The project is short TUTORIALS POINT
Waterfall Model Pros & Cons
The advantage of waterfall development is that it allows for departmentalization and
control. A schedule can be set with deadlines for each stage of development and a product
can proceed through the development process model phases one by one. Development
moves from concept, through design, implementation, testing, installation, troubleshooting,
and ends up at operation and maintenance. Each phase of development proceeds in strict
order.
The disadvantage of waterfall development is that it does not allow for much reflection or

revision. Once an application is in the testing stage, it is very difficult to go back and
change something that was not well-documented or thought upon in the concept stage.
The following table lists out the pros and cons of Waterfall model:
Iterative Model
In Iterative model, iterative process starts with a simple implementation of a small set of
the software requirements and iteratively enhances the evolving versions until the complete
system is implemented and ready to be deployed.
An iterative life cycle model does not attempt to start with a full specification of
requirements. Instead, development begins by specifying and implementing just part of the
software, which is then reviewed in order to identify further requirements. This process is
then repeated, producing a new version of the software at the end of each iteration of the
model.
Iterative Model design
Iterative process starts with a simple implementation of a subset of the software
requirements and iteratively enhances the evolving versions until the full system is
implemented. At each iteration, design modifications are made and new functional
capabilities are added. The basic idea behind this method is to develop a system through
repeated cycles (iterative) and in smaller portions at a time (incremental).
Following is the pictorial representation of Iterative and Incremental model:

Iterative and Incremental development is a combination of both iterative design or iterative
method and incremental build model for development. "During software development,
more than one iteration of the software development cycle may be in progress at the same
time." and "This process may be described as an "evolutionary acquisition" or "incremental
build" approach."
In incremental model the whole requirement is divided into various builds. During each
iteration, the development module goes through the requirements, design, implementation
and testing phases. Each subsequent release of the module adds function to the previous
release. The process continues till the complete system is ready as per the requirement.
The key to successful use of an iterative software development lifecycle is rigorous
validation of requirements, and verification & testing of each version of the software
against those requirements within each cycle of the model. As the software evolves through
successive cycles, tests have to be repeated and extended to verify each version of the
software.
Iterative Model Application
Like other SDLC models, Iterative and incremental development has some specific
applications in the software industry. This model is most often used in the following
scenarios:
 Requirements of the complete system are clearly defined and understood.
 Major requirements must be defined; however, some functionalities or requested
enhancements may evolve with time.
 There is a time to the market constraint.
 A new technology is being used and is being learnt by the development team while
working on the project.
 Resources with needed skill set are not available and are planned to be used on contract
basis for specific iterations.
 There are some high risk features and goals which may change in the future.

Iterative Model Pros and Cons
The advantage of this model is that there is a working model of the system at a very early
stage of development which makes it easier to find functional or design flaws. Finding
issues at an early stage of development enables to take corrective measures in a limited
budget.
The disadvantage with this SDLC model is that it is applicable only to large and bulky
software development projects. This is because it is hard to break a small software system
into further small serviceable increments/modules.
The following table lists out the pros and cons of Iterative and Incremental SDLC Model:
Spiral Model
The spiral model combines the idea of iterative development with the systematic, controlled
aspects of the waterfall model.
Spiral model is a combination of iterative development process model and sequential linear
development model i.e. waterfall model with very high emphasis on risk analysis. It allows
for incremental releases of the product, or incremental refinement through each iteration
around the spiral.
Spiral Model design
The spiral model has four phases. A software project repeatedly passes through these
phases in iterations called Spirals.

 Identification
This phase starts with gathering the business requirements in the baseline spiral. In the
subsequent spirals as the product matures, identification of system requirements, subsystem
requirements and unit requirements are all done in this phase.
This also includes understanding the system requirements by continuous communication
between the customer and the system analyst. At the end of the spiral the product is
deployed in the identified market.
Following is a diagrammatic representation of spiral model listing the activities in each
phase
 Design
Design phase starts with the conceptual design in the baseline spiral and involves
architectural design, logical design of modules, physical product design and final design in
the subsequent spirals.
 Construct or Build
Construct phase refers to production of the actual software product at every spiral. In
the baseline spiral when the product is just thought of and the design is being developed a
POC (Proof of Concept) is developed in this phase to get customer feedback.
Then in the subsequent spirals with higher clarity on requirements and design details a
working model of the software called build is produced with a version number. These
builds are sent to customer for feedback.
 Evaluation and Risk Analysis
Risk Analysis includes identifying, estimating, and monitoring technical feasibility and
management risks, such as schedule slippage and cost overrun. After testing the build, at

the end of first iteration, the customer evaluates the software and provides feedback.
Based on the customer evaluation, software development process enters into the next
iteration and subsequently follows the linear approach to implement the feedback suggested
by the customer. The process of iterations along the spiral continues throughout the life of
the software.
Spiral Model Application
Spiral Model is very widely used in the software industry as it is in synch with the natural
development process of any product i.e. learning with maturity and also involves minimum
risk for the customer as well as the development firms. Following are the typical uses of
Spiral model:
 When costs there is a budget constraint and risk evaluation is important
 For medium to high-risk projects
 Long-term project commitment because of potential changes to economic priorities as
the requirements change with time
 Customer is not sure of their requirements which is usually the case
 Requirements are complex and need evaluation to get clarity
 New product line which should be released in phases to get enough customer feedback
 Significant changes are expected in the product during the development cycle
Spiral Model Pros and Cons
The advantage of spiral lifecycle model is that it allows for elements of the product to be
added in when they become available or known. This assures that there is no conflict with
previous requirements and design. This method is consistent with approaches that have
multiple software builds and releases and allows for making an orderly transition to a
maintenance activity. Another positive aspect is that the spiral model forces early user
involvement in the system development effort.
On the other side, it takes very strict management to complete such products and there is a
risk of running the spiral in indefinite loop. So the discipline of change and the extent of
taking change requests are very important to develop and deploy the product successfully.
The following table lists out the pros and cons of Spiral SDLC Model:

V – Model
The V- model is SDLC model where execution of processes happens in a sequential
manner in V-shape. It is also known as Verification and Validation model.
V-Model is an extension of the waterfall model and is based on association of a testing
phase for each corresponding development stage. This means that for every single phase in
the development cycle there is a directly associated testing phase. This is a highly
disciplined model and next phase starts only after completion of the previous phase.
V- Model design
Under V-Model, the corresponding testing phase of the development phase is planned in
parallel. So there are Verification phases on one side of the ‘V’ and Validation phases on
the other side. Coding phase joins the two sides of the V-Model.
The below figure illustrates the different phases in V-Model of SDLC.
Verification Phases

Following are the Verification phases in V-Model:
 Business Requirement Analysis :
This is the first phase in the development cycle where the product requirements are
understood from the customer perspective. This phase involves detailed communication
with the customer to understand his expectations and exact requirement. This is a very
important activity and need to be managed well, as most of the customers are not sure
about what exactly they need. The acceptance test design planning is done at this stage as
business requirements can be used as an input for acceptance testing.
 System Design:
Once you have the clear and detailed product requirements, it’s time to design the complete
system. System design would comprise of understanding and detailing the complete
hardware and communication setup for the product under development. System test plan is
developed based on the system design. Doing this at an earlier stage leaves more time for
actual test execution later.
 Architectural Design:
Architectural specifications are understood and designed in this phase. Usually more than
one technical approach is proposed and based on the technical and financial feasibility the
final decision is taken. System design is broken down further into modules taking up
different functionality. This is also referred to as High Level Design (HLD).
The data transfer and communication between the internal modules and with the outside
world (other systems) is clearly understood and defined in this stage. With this information,
integration tests can be designed and documented during this stage.
 Module Design:
In this phase the detailed internal design for all the system modules is specified, referred to
as Low Level Design (LLD). It is important that the design is compatible with the other
modules in the system architecture and the other external systems.
Unit tests are an essential part of any development process and helps eliminate the
maximum faults and errors at a very early stage. Unit tests can be designed at this stage
based on the internal module designs.
Coding Phase
The actual coding of the system modules designed in the design phase is taken up in the
Coding phase. The best suitable programming language is decided based on the system and
architectural requirements. The coding is performed based on the coding guidelines and
standards. The code goes through numerous code reviews and is optimized for best
performance before the final build is checked into the repository.

Validation Phases
Following are the Validation phases in V-Model:
 Unit Testing
Unit tests designed in the module design phase are executed on the code during this
validation phase. Unit testing is the testing at code level and helps eliminate bugs at an
early stage, though all defects cannot be uncovered by unit testing.
 Integration Testing
Integration testing is associated with the architectural design phase. Integration tests are
performed to test the coexistence and communication of the internal modules within the
system.
 System Testing
System testing is directly associated with the System design phase. System tests check the
entire system functionality and the communication of the system under development with
external systems. Most of the software and hardware compatibility issues can be uncovered
during system test execution.
 Acceptance Testing
Acceptance testing is associated with the business requirement analysis phase and involves
testing the product in user environment. Acceptance tests uncover the compatibility issues
with the other systems available in the user environment. It also discovers the non
functional issues such as load and performance defects in the actual user environment.
V- Model Application
V- Model application is almost same as waterfall model, as both the models are of
sequential type. Requirements have to be very clear before the project starts, because it is
usually expensive to go back and make changes. This model is used in the medical
development field, as it is strictly disciplined domain. Following are the suitable scenarios
to use V-Model:
 Requirements are well defined, clearly documented and fixed.
 Product definition is stable.
 Technology is not dynamic and is well understood by the project team.
 There are no ambiguous or undefined requirements
 The project is short.
V- Model Pros and Cons
The advantage of V-Model is that it’s very easy to understand and apply. The simplicity of
this model also makes it easier to manage. The disadvantage is that the model is not flexible
to changes and just in case there is a requirement change, which is very common in today’s
dynamic world, it becomes very expensive to make the change.

Big Bang Model
The Big Bang model is SDLC model where there is no specific process followed. The
development just starts with the required money and efforts as the input, and the output is
the software developed which may or may not be as per customer requirement.
Big Bang Model is SDLC model where there is no formal development followed and very
little planning is required. Even the customer is not sure about what exactly he wants and
the requirements are implemented on the fly without much analysis. Usually this model is
followed for small projects where the development teams are very small.
Big Bang Model design and Application
Big bang model comprises of focusing all the possible resources in software development
and coding, with very little or no planning. The requirements are understood and
implemented as they come. Any changes required may or may not need to revamp the
complete software.
This model is ideal for small projects with one or two developers working together and is
also useful for academic or practice projects. It’s an ideal model for the product where
requirements are not well understood and the final release date is not given.
Big Bang Model Pros and Cons
The advantage of Big Bang is that it’s very simple and requires very little or no planning.
Easy to mange and no formal procedure are required.
However the Big Bang model is a very high risk model and changes in the requirements or
misunderstood requirements may even lead to complete reversal or scraping of the project.
It is ideal for repetitive or small projects with minimum risks.
Agile Model
Agile SDLC model is a combination of iterative and incremental process models with focus
on process adaptability and customer satisfaction by rapid delivery of working software
product.
Agile Methods break the product into small incremental builds. These builds are provided
in iterations. Each iteration typically lasts from about one to three weeks. Every iteration
involves cross functional teams working simultaneously on various areas like planning,
requirements analysis, design, coding, unit testing, and acceptance testing. At the end of the
iteration a working product is displayed to the customer and important stakeholders.
What is Agile?

Agile model believes that every project needs to be handled differently and the existing
methods need to be tailored to best suit the project requirements. In agile the tasks are
divided to time boxes (small time frames) to deliver specific features for a release. Iterative
approach is taken and working software build is delivered after each iteration. Each build is
incremental in terms of features; the final build holds all the features required by the
customer.
Here is a graphical illustration of the Agile Model:
Agile thought process had started early in the software development and started becoming
popular with time due to its flexibility and adaptability. The most popular agile methods
include Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme
Programming (1996), Adaptive Software Development, Feature Driven Development, and
Dynamic Systems Development Method (DSDM) (1995). These are now collectively
referred to as agile methodologies, after the Agile Manifesto was published in 2001.
Following are the Agile Manifesto principles:
 Individuals and interactions –
in agile development, self-organization and motivation are important, as are interactions
like co-location and pair programming.
 Working software –
Demo working software is considered the best means of communication with the customer
to understand their requirement, instead of just depending on documentation.
 Customer collaboration –
As the requirements cannot be gathered completely in the beginning of the project due to
various factors, continuous customer interaction is very important to get proper product
requirements.

 Responding to change –
agile development is focused on quick responses to change and continuous development.
Agile Vs Traditional SDLC Models
Agile Model Pros and Cons
Agile methods are being widely accepted in the software world recently, however, this
method may not always be suitable for all products. Here are some pros and cons of the
agile model.

7. PROJECT IN LEAN
7.1 Lean software development:
Lean software development:
Lean software development (LSD) is a translation of lean manufacturing and lean IT
principles and practices to the software development domain. Adapted from the Toyota
Production System,[1] a pro-lean subculture is emerging from within the Agile community.
Origin
The term lean software development originated in a book by the same name, written by
Mary Poppendieck and Tom Poppendieck.[2] The book presents the traditional lean
principles in a modified form, as well as a set of 22 tools and compares the tools to agile
practices. The Poppendiecks' involvement in the Agile software development community,
including talks at several Agile conferences [3] has resulted in such concepts being more
widely accepted within the Agile community.
Lean principles
Lean development can be summarized by seven principles, very close in concept to lean
manufacturing principles:
• Eliminate waste
• Amplify learning
• Decide as late as possible
• Deliver as fast as possible
• Empower the team
• Build integrity in
• See the whole
Eliminate waste
Lean philosophy regards everything not adding value to the customer as waste (muda).
Such waste may include:
• unnecessary code and functionality
• delay in the software development process
• unclear requirements
• insufficient testing (leading to avoidable process repetition)
• bureaucracy
• slow internal communication

In order to eliminate waste, one should be able to recognize it. If some activity could be
bypassed or the result could be achieved without it, it is waste. Partially done coding
eventually abandoned during the development process is waste. Extra processes and
features not often used by customers are waste. Waiting for other activities, teams,
processes is waste. Defects and lower quality are waste. Managerial overhead not
producing real value is waste.
A value stream mapping technique is used to identify waste. The second step is to point out
sources of waste and to eliminate them. Waste-removal should take place iteratively until
even essential-seeming processes and procedures are liquidated.
Amplify learning
Software development is a continuous learning process with the additional challenge of
development teams and end product sizes. The best approach for improving a software
development environment is to amplify learning. The accumulation of defects should be
prevented by running tests as soon as the code is written. Instead of adding more
documentation or detailed planning, different ideas could be tried by writing code and
building. The process of user requirements gathering could be simplified by presenting
screens to the end-users and getting their input.
The learning process is sped up by usage of short iteration cycles – each one coupled with
refactoring and integration testing. Increasing feedback via short feedback sessions with
customers helps when determining the current phase of development and adjusting efforts
for future improvements. During those short sessions both customer representatives and the
development team learn more about the domain problem and figure out possible solutions
for further development. Thus the customers better understand their needs, based on the
existing result of development efforts, and the developers learn how to better satisfy those
needs. Another idea in the communication and learning process with a customer is set-
based development – this concentrates on communicating the constraints of the future
solution and not the possible solutions, thus promoting the birth of the solution via dialogue
with the customer.
Decide as late as possible
As software development is always associated with some uncertainty, better results should
be achieved with an options-based approach, delaying decisions as much as possible until
they can be made based on facts and not on uncertain assumptions and predictions. The
more complex a system is, the more capacity for change should be built into it, thus
enabling the delay of important and crucial commitments. The iterative approach promotes
this principle – the ability to adapt to changes and correct mistakes, which might be very
costly if discovered after the release of the system.
An agile software development approach can move the building of options earlier for
customers, thus delaying certain crucial decisions until customers have realized their needs
better. This also allows later adaptation to changes and the prevention of costly earlier
technology-bounded decisions. This does not mean that no planning should be involved –
on the contrary, planning activities should be concentrated on the different options and
adapting to the current situation, as well as clarifying confusing situations by establishing

patterns for rapid action. Evaluating different options is effective as soon as it is realized
that they are not free, but provide the needed flexibility for late decision making.
Deliver as fast as possible
In the era of rapid technology evolution, it is not the biggest that survives, but the fastest.
The sooner the end product is delivered without major defects, the sooner feedback can be
received, and incorporated into the next iteration. The shorter the iterations, the better the
learning and communication within the team. With speed, decisions can be delayed. Speed
assures the fulfilling of the customer's present needs and not what they required yesterday.
This gives them the opportunity to delay making up their minds about what they really
require until they gain better knowledge. Customers value rapid delivery of a quality
product.
The just-in-time production ideology could be applied to software development,
recognizing its specific requirements and environment. This is achieved by presenting the
needed result and letting the team organize itself and divide the tasks for accomplishing the
needed result for a specific iteration. At the beginning, the customer provides the needed
input. This could be simply presented in small cards or stories – the developers estimate the
time needed for the implementation of each card. Thus the work organization changes into
self-pulling system – each morning during a stand-up meeting, each member of the team
reviews what has been done yesterday, what is to be done today and tomorrow, and
prompts for any inputs needed from colleagues or the customer. This requires transparency
of the process, which is also beneficial for team communication. Another key idea in
Toyota's Product Development System is set-based design. If a new brake system is needed
for a car, for example, three teams may design solutions to the same problem. Each team
learns about the problem space and designs a potential solution. As a solution is deemed
unreasonable, it is cut. At the end of a period, the surviving designs are compared and one
is chosen, perhaps with some modifications based on learning from the others - a great
example of deferring commitment until the last possible moment. Software decisions could
also benefit from this practice to minimize the risk brought on by big up-front design.
Empower the team
There has been a traditional belief in most businesses about the decision-making in the
organization – the managers tell the workers how to do their own job. In a "Work-Out
technique", the roles are turned – the managers are taught how to listen to the developers,
so they can explain better what actions might be taken, as well as provide suggestions for
improvements. The lean approach favours the aphorism "find good people and let them do
their own job," encouraging progress, catching errors, and removing impediments, but not
micro-managing.
Another mistaken belief has been the consideration of people as resources. People might be
resources from the point of view of a statistical data sheet, but in software development, as
well as any organizational business, people do need something more than just the list of
tasks and the assurance that they will not be disturbed during the completion of the tasks.
People need motivation and a higher purpose to work for – purpose within the reachable
reality, with the assurance that the team might choose its own commitments. The

developers should be given access to the customer; the team leader should provide support
and help in difficult situations, as well as ensure that skepticism does not ruin the team’s
spirit.
Build integrity in
The customer needs to have an overall experience of the System – this is the so-called
perceived integrity: how it is being advertised, delivered, deployed, accessed, how intuitive
its use is, price and how well it solves problems.
Conceptual integrity means that the system’s separate components work well together as a
whole with balance between flexibility, maintainability, efficiency, and responsiveness.
This could be achieved by understanding the problem domain and solving it at the same
time, not sequentially. The needed information is received in small batch pieces – not in
one vast chunk with preferable face-to-face communication and not any written
documentation. The information flow should be constant in both directions – from
customer to developers and back, thus avoiding the large stressful amount of information
after long development in isolation.
One of the healthy ways towards integral architecture is refactoring. As more features are
added to the original code base, the harder it becomes to add further improvements.
Refactoring is about keeping simplicity, clarity, minimum amount of features in the code.
Repetitions in the code are signs for bad code designs and should be avoided. The complete
and automated building process should be accompanied by a complete and automated suite
of developer and customer tests, having the same versioning, synchronization and
semantics as the current state of the System. At the end the integrity should be verified with
thorough testing, thus ensuring the System does what the customer expects it to. Automated
tests are also considered part of the production process, and therefore if they do not add
value they should be considered waste. Automated testing should not be a goal, but rather a
means to an end, specifically the reduction of defects.
See the whole
Software systems nowadays are not simply the sum of their parts, but also the product of
their interactions. Defects in software tend to accumulate during the development process –
by decomposing the big tasks into smaller tasks, and by standardizing different stages of
development, the root causes of defects should be found and eliminated. The larger the
system, the more organizations that are involved in its development and the more parts are
developed by different teams, the greater the importance of having well defined
relationships between different vendors, in order to produce a system with smoothly
interacting components. During a longer period of development, a stronger subcontractor
network is far more beneficial than short-term profit optimizing, which does not enable
win-win relationships.
Lean thinking has to be understood well by all members of a project, before implementing
in a concrete, real-life situation. "Think big, act small, fail fast; learn rapidly" – these
slogans summarize the importance of understanding the field and the suitability of
implementing lean principles along the whole software development process. Only when
all of the lean principles are implemented together, combined with strong "common sense"

with respect to the working environment, is there a basis for success in software
development.
Lean software practices
Lean software development practices, or what the Poppendiecks call "tools" are expressed
slightly differently from their equivalents in Agile software development, but there are
parallels. Examples of such practices include:
• Seeing waste
• Value stream mapping
• Set-based development
• Pull systems
• Queuing theory
• Motivation
• Measurements
Some of the tools map quite easily to Agile methods. Lean Workcells, for example are
expressed in Agile methods as cross-functional teams.

8. A STUDY IN PROJECT FAILURE
1)
Research highlights that only one in eight information technology projects can be considered
truly successful (failure being described as those projects that do not meet the original time,
cost and (quality) requirements criteria).
Despite such failures, huge sums continue to be invested in information systems projects and
written off. For example the cost of project failure across the European Union was €142
billion in 2004.
The research looked at 214 information systems (IS) projects at the same time, interviews
were conducted with a selective number of project managers to follow up issues or clarify
points of interest. The period of analysis covered 1998-2005 the number of information
systems projects examined across the European Union.
Number of IS projects examined within European Union
Rank Sector No. of projects examined
1 Manufacturing 43
2 Retail 36
3 Financial services 33
4 Transport 27
5 Health 18
6 Education 17
7 Defence 13
8 Construction 12
9 Logistics 9
10 Agriculture 6
Total 214
Project value in millions of Euros
Value range in millions (€)Number of
projects
Percentage
(%)
Accumulative
(%)
0 – 1 51 23.831 23.831
1 – 2 20 9.346 33.177
2 - 3 11 5.140 38.317
3 - 5 33 15.421 53.738
5 - 10 4 1.869 55.607
10 - 20 87 40.654 96.261

20 - 50 6 2.804 99.065
50 - 80 2 0.935 100.000
Totals 214 100.00 100.00
At what stage in the project lifecycle are projects cancelled (or abandoned as
failures)?
Prior research by the authors in 2002 identified that 7 out of 10 software projects undertaken
in the UK adopted the waterfall method for software development and delivery. Results
from the analysis of cases indicates that almost one in four of the projects examined were
abandoned after the feasibility stage of those projects completed approximately one in three
were schedule and budget overruns.
Project completions, cancellations and overruns
Waterfall
method
lifecycle stage
Number of
projects
cancelled
Number of
projects
completed
Number of
projects
overrun
(schedule
and/or cost)
Feasibility None 214 None
Requirements
analysis
3 211 None
Design 28 183 32
Code 15 168 57
Testing 4 164 57
Implementation 1 163 69
Handover None 163 69
Percentages 23.8% 76.2%
Of the initial 214 projects studied 51 (23.8 per cent were cancelled) - a summary of the
principal reasons why projects were cancelled is given below. Our earlier research
elaborated on the symptoms of information systems project failure in three specific areas:
frequent requests by users to change the system; insufficient communication between the
different members of the team working on the project and the end users (stakeholders); and
no clear requirements definitions. Whilst communication between team and end users was
still perceived as an issue within some projects; the top three issues from this study are:
business process alignment; requirements management; and overspends.
One notable causal factor in these abandonment's was the lack of due diligence at the
requirements phase, an important factor here was the level of skill in design and poor
management judgement in selecting software engineers with the right skill sets. Equally the
authors found some evidence in poor tool set selection in that end users found it difficult to

sign-off design work - in that they could not relate process and data model output with their
reality and practical knowledge of the business processes.
Key reasons why projects get cancelled
• Business reasons for project failure
• Business strategy superseded;
• Business processes change (poor alignment);
• Poor requirements management;
• Business benefits not clearly communicated or overstated;
• Failure of parent company to deliver;
• Governance issues within the contract;
• Higher cost of capital;
• Inability to provide investment capital;
• Inappropriate disaster recovery;
• Misuse of financial resources;
• Overspends in excess of agreed budgets;
• Poor project board composition;
• Take-over of client firm;
• Too big a project portfolio.
Management reasons
• Ability to adapt to new resource combinations;
• Differences between management and client;
• Insufficient risk management;
• Insufficient end-user management;
• Insufficient domain knowledge;
• Insufficient software metrics;
• Insufficient training of users;
• Inappropriate procedures and routines;
• Lack of management judgement;

• Lack of software development metrics;
• Loss of key personnel;
• Managing legacy replacement;
• Poor vendor management
• Poor software productivity;
• Poor communication between stakeholders;
• Poor contract management;
• Poor financial management;
• Project management capability;
• Poor delegation and decision making;
• Unfilled promises to users and other stakeholders.
Technical Reasons
• Inappropriate architecture;
• Insufficient reuse of existing technical objects;
• Inappropriate testing tools;
• Inappropriate coding language;
• Inappropriate technical methodologies;
• Lack of formal technical standards;
• Lack of technical innovation (obsolescence);
• Misstatement of technical risk;
• Obsolescence of technology;
• Poor interface specifications;
• Poor quality code;
• Poor systems testing;
• Poor data migration;
• Poor systems integration;
• Poor configuration management;
• Poor change management procedures;
• Poor technical judgement.

What is the average schedule and budget overrun?
In examining the cases it was noted that the average duration of a project was just over 26
months (115 weeks) and the average budget was approximate 6 million Euros, (Table 5). In
many instances information on a project being over schedule and over budget will force
senior management to act, however, the search for the underlying factors should begin
elsewhere in the projects history.
The pattern that emerges from a synthesis of case data is complex and multifaceted. In a few
of the of cases examined the project commentary and history was ambiguous; however, once
a decision had been made to support a project which was over schedule or over budget the
ends usually justified the means irrespective of the viewpoints of individual project
managers or stakeholders.
Cost and schedule overruns (N=69)
Projects
From
Sample
2
(2)
11
(13)
19
(32)
25
(57)
12
(69)
Schedule
Overrun
11
weeks
29
weeks
46
weeks
80
weeks
103
weeks
Range Average
Budget +
10%
Average
Budget +
25%
Average
Budget +
40%
Average
Budget +
70%
Average
Budget +
90%
Cost
Overrun
€600,000 €1,500,000 €2,400,000 €4,200,000 €5,400,000
What are the major causal factors contributing to project failure?
Judgements by project stakeholders about the relative success or failure of projects tend to
be made early in the projects life cycle. On examination of the project stage reports it
became apparent that many project managers plan for failure rather than success.
If we consider the inherent complexity of risk associated with software project delivery it is
not too surprising that only a small number of projects are delivered to the original time,
cost, and quality requirements.
Our evidence suggests that the culture within many organisations is often such that
leadership, stakeholder and risk management issues are not factored into projects early on
and in many instances cannot formally be written down for political reasons and are rarely
discussed openly at project board or steering group meetings although they may be
discussed at length behind closed doors.

Despite attempts to make software development and project delivery more rigorous, a
considerable proportion of delivery effort results in systems that do not meet user
expectations and are subsequently cancelled. In our view this is attributed to the fact that
very few organisation's have the infrastructure, education, training, or management
discipline to bring projects to successful completion.
One of the major weaknesses uncovered during the analysis was the total reliance placed on
project and development methodologies. One explanation for the reliance on methodology is
the absence of leadership within the delivery process. Processes alone are far from enough to
cover the complexity and human aspects of many large projects subject to multiple
stakeholders, resource and ethical constraints.
Although our understanding of the importance of project failure has increased, the
underlying reasons still remain an issue and a point of contention for both practitioners and
academics alike. Without doubt there is still a lot to learn from studying project failure.
Going back to the research undertaken there is little evidence that the issues of project
failure have been fully addressed within information systems project management. Based on
this research project failure requires recognition of the influence multiple stakeholders have
on projects, and a broad based view of project leadership and stakeholder management.
Developing an alternative methodology for project management founded on a leadership,
stakeholder and risk management should lead to a better understanding of the management
issues that may contribute to the successful delivery of information systems projects.
2)
What is Project Failure?
Definition of Project Failure
IT project failures are far more common than most people expect. In the last decade
numerous studies and surveys on IT projects have shown that the success rate is around
25%, the failure rate is about 25%, and partial successes and failures fall somewhere in the
middle. Typically, there are two types of project failure namely:
A project that consumes resources but fails to deliver an acceptable Return on Investment
(ROI), is terminated before completion, or is poorly scoped so resource allocation is
insufficient. This results in low adoption, or produces insufficient value and no learning
lessons. This can be deemed a project failure.
Another project failure is one that consumes resources but fails to deliver as proposed,
exceeds its budget, exceeds its time, and doesn't meet specifications.
Analysts Reports on the Problem

KPMG International's Survey of 600 organizations across 22 countries revealed that 86%
of respondents reported the loss of up to a quarter of their targeted benefits across their
project portfolios. Nearly half of respondents reported at least one project failure in the past
year, an improvement from KPMG’s 2003 survey where 57% experienced one or more
project failures in the previous 12 months. 86% of projects have a business case but over
60% ignore it.
Sources: KPMG in Information Age April/May 2006.
Standish CHAOS Chronicles v3.0
This was the earliest and first report (1994) by a research group on the subject of project
failures. Standish followed up the article every 2 years with new research. The "Extreme
CHAOS 2001" report found a steadying improvement in the success rate of projects. The
reasons for the increase (1994 to 2000) in successful projects vary. The average cost of a
project has been more than cut in half. Better tools have been created to monitor and
control progress, and more highly skilled project managers are using improved
management processes. The fact that there are processes is significant in itself. Most of
these new projects are well within The Standish Group's criteria established in "Recipe for
Success, 1998," which limits project duration to six months and project staff to six people.
"A quarter of the benefits of IT projects are being lost by organizations across the globe
because of management failures during a project’s lifecycle..."
Source: KPMG International survey, Nov 2005
In the latest CHAOS Summary 2009 report from The Standish Group, that surveyed 400
organizations, found that IT project success rates were dropping. In the past two years, it
found that 24% were considered a failure (cancelled before completion or never used). Up
to 44% were considered challenged and 32 % were considered successful, completed on
time, and on budget.
Does Project Failure Happen Often?
There is evidence to support that project success rates are rising. The original Standish's
1994 CHAOS study found that only 16% projects met the criteria for success—completed
on time, on budget, and with all the features and functions originally specified. In
subsequent studies this rate has improved and project failures have decreased.
Sources: http://www.softwaremag.com/archive/2001feb/CollaborativeMgt.html and
“Chaos, a recipe for success”, Standish Group, 1998
For 2004 results show that 29% of all projects succeeded (delivered on time, on budget,
with required features and functions); 53% are challenged (late, over budget and/or with
less than the required features and functions); and 18% have failed (cancelled prior to
completion or delivered and never used). A staggering 66% of IT projects prove
unsuccessful in some measure, whether they fail completely, exceed their allotted budget,
aren't completed according to schedule or are rolled out with fewer features and functions
than promised.
Sources: http://www.standishgroup.com/sample_research/PDFpages/q3-spotlight.pdf
Chaos, 2004

Software Project Management-An overview

Software Project Management-An overview

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Software Project Management-An overview

Similar to Software Project Management-An overview (20)

Software Project Management-An overview