You are on page 1of 37

Software Project Management

M P Sebastian, IIM Kozhikode

Outline

Define software project management


SDLC
Software lifecycle Models
Waterfall Model
V-shaped Model
Prototyping Model
Spiral Model
Incremental Model
RAD Model
Agile Methods
ERP Project Management
Choices for ERP implementation
ERP implementation lifecycle

What is a project?

Jobs

Exploration

e.g., Search for extraterrestrial intelligence: the outcome is very uncertain

Projects

Repetition of very well-defined and well understood tasks with very little uncertainty

in the middle!

Characteristics of Projects

A task is more project-like if it is:

Non-routine

Planned

Aiming at a specific target

Work carried out for a customer

Involving several specialisms

Made up of several different phases

Constrained by time and resources

Large and/or complex

Are software projects really different from other projects?


Similar, but

Invisibility

Complexity

Conformity

Flexibility

make software more problematic to build than other engineered artefacts.

SPM Activities

A software project is not only concerned with the actual writing of software.

When a software application is bought 'off the shelf

there may be no software writing as such, but this is still fundamentally a software project
because so many of the other activities associated with software will still be present.

Feasibility study
Is project technically feasible and worthwhile from a business point of view?

Planning
Only done if project is feasible

Execution
Implement plan, but plan may be changed as we go along

Systems Engineering

Specifying, designing, implementing, validating, deploying and maintaining socio-technical


systems.

Concerned with the services provided by the system, constraints on its construction and operation
and the ways in which it is used.

The process usually follows a waterfall model

Little scope for iteration between phases because hardware changes are very expensive.
Software may have to compensate for hardware problems.

System Development Life


Cycle: The Waterfall Model

Requirements
Definition

System
Design
Subsystem
Development

System
Integration/
testing

System
Installation
System
Evolution
System
Decommissioning

Prof M P Sebastian, IIM Kozhikode

3/22/2015

Case: Buying Off-the-Shelf Product

Nalanda College is a higher education institution which used to be managed by a local


government authority but has now become autonomous. Its payroll is still administered by the
local authority and payslips and other output are produced in the local authority's computer
centre. The authority now charges the college for this service. The college management is of the
opinion that it would be cheaper to obtain an 'off-the shelf' payroll package and do the payroll
processing themselves.

What would be the main stages of the project to convert to independent payroll processing by
the college?

Bearing in mind that an off-the-shelf package is to be used, how would this project differ
from one where the software was to be written from scratch?

Nalanda College payroll: stages of a project


1. Project evaluation:

All the costs that would be incurred by the college if it were to carry out its own payroll
processing would need to be carefully examined to ensure that it would be more costeffective than letting the local authority carryon providing the service.

2. Planning:

The way that the transfer to local processing is to be carried out needs to be carefully
planned with the participation of all those concerned. Some detailed planning would need
to be deferred until more information was available, for example which payroll package
was to be used.

2. Requirements elicitation and analysis:

Prof M P Sebastian, IIM Kozhikode

3/22/2015

16

This is finding out what the users need from the system. To a large extent it will often
consist of finding out what the current system does, as it may be assumed that in general
the new system is to provide the same functions as the old. The users might have
additional requirements, however, or there might even be facilities that are no longer
needed.

4. Specification:

This involves documenting what the new system is to be able to do.

5. Design/coding:

As an 'off-the-shelf' package is envisaged, these stages will be replaced by a package


evaluation and selection activity.

6. Verification and validation:

Verification: Are we building the product right?

Validation: Are we building the right product?

Tests will need to be carried out to ensure that the selected package will actually do what
is required. This task might well involve parallel running of the old and new systems and
a comparison of the output from them both to check for any inconsistencies.

7. Implementation:

This would involve such things as installing the software, setting system parameters such
as the salary scales, and setting up details of employees.

8. Maintenance/support:

This will include dealing with users' queries, liaising with the package supplier and taking
account of new payroll requirements.

Software Processes and Process Models

A software product development process usually starts when a request for the product is received
from the customer.

From the inception stage, a product undergoes a series of transformations through a few
identifiable stages until it is fully developed and released to the customer.

After release, the product is used by the customer and during this time the product needs to be
maintained for fixing bugs and enhancing functionalities. This stage is called the maintenance
stage. When the product is no longer useful to the customer, it is retired.

This set of identifiable stages through which a product transits from inception to retirement form
the life cycle of the product.

Case: Nalanda College Payroll life cycle stages


1. Requirements Elicitation and Analysis
2. Specification
3. Change Requirements Analysis: Determine the differences between the requirements of
Nalanda College and that for its existing product.
4. Design Change Analysis: Identify the design parts of the pay roll software that would not be
needed, be excluded, changed, and the ones that would have to be developed again.
5. Design: Design those parts that have to be developed again and change the design of those that
need modification.
6. Code and Test: Code the new parts and carry out modifications to the code of the parts that
need to be changed; and then test these.
7. Verification and Validation
8. Implementation

9. Maintenance or Support

How the customer explained it

How the project leader understood it


Prof M P Sebastian, IIM Kozhikode

3/22/2015

How the analyst designed it

How the programmer wrote it


Prof M P Sebastian, IIM Kozhikode

3/22/2015

19

How the business consultant described it

How the project was documented


Prof M P Sebastian, IIM Kozhikode

3/22/2015

20

What operations installed

How the customer was billed


Prof M P Sebastian, IIM Kozhikode

3/22/2015

21

How it was supported

What the customer really needed


Holly Hyland Holly.Hyland@ed.gov, Jim McMahon James.McMahon@ed.gov
Prof M P Sebastian, IIM Kozhikode

3/22/2015

22

Generic Software Process Models


1. The waterfall model
2. V-shaped waterfall model
3. Evolutionary development
4. Spiral Model
5. Incremental delivery
6. Rapid Application Model

Component-based software engineering

The system is assembled from existing components.

There are many variants of these models e.g. formal development where a waterfall-like process
is used but the specification is a formal specification that is refined through several stages to an
implementable design.

1. The Waterfall Model

This is the 'classical' model of system development that is also known as the one-shot or oncethrough model.

The flow of a waterfall should be downwards, with the possibility of just a little splashing back.

The limited scope for iteration is in fact one of the strengths of this process model. With a large
project you want to avoid reworking tasks previously thought to be completed.

Having to reopen completed activities plays havoc with promised completion dates.

Waterfall Strengths

1. Easy to understand, easy to use


2. Provides structure to inexperienced staff
3. Milestones are well understood
4. Sets requirements stability
5. Good for management control (plan, staff, track)
6. Works well when quality is more important than cost or schedule

Waterfall Deficiencies

1. All requirements must be known upfront


2. Deliverables created for each phase are considered frozen inhibits flexibility
3. Can give a false impression of progress
4. Does not reflect problem-solving nature of software development iterations of phases
5. Integration is one big bang at the end
6. Little opportunity for customer to preview the system (until it may be too late)

When to use the Waterfall Model

Requirements are very well known

Product definition is stable

Technology is understood

New version of an existing product

Porting an existing product to a new platform.

2. V-Shaped Model

A variant of the Waterfall that emphasizes the verification and validation of the product.

Testing of the product is planned in parallel with a corresponding phase of development

Verification/
validation

Project
Definition

Project
testing and
integration

Time

Prof M P Sebastian, IIM Kozhikode

29

V-Shaped Strengths

1. Emphasize planning for verification and validation of the product in early stages of product
development
2. Each deliverable must be testable
3. Project management can track progress by milestones
4. Easy to use

V-Shaped Weaknesses

1. Does not easily handle concurrent events


2. Does not handle iterations or phases
3. Does not easily handle dynamic changes in requirements
4. Does not contain risk analysis activities

When to use the V-Shaped Model

Excellent choice for systems requiring high reliability hospital patient control applications

All requirements are known up-front

When it can be modified to handle changing requirements beyond analysis phase

Solution and technology are known

3. Structured Evolutionary Prototyping Model

Developers build a prototype during the requirements phase

Prototype is evaluated by end users

Users give corrective feedback

Developers further refine the prototype

When the user is satisfied, the prototype code is brought up to the standards needed for a final
product.

Evolutionary Prototyping Steps

A preliminary project plan is developed

A partial high-level paper model is created

The model is a source for a partial requirements specification

A prototype is built with basic and critical attributes

The designer builds

the database

user interface

algorithmic functions

The designer demonstrates the prototype, the user evaluates for problems and suggests
improvements

This loop continues until the user is satisfied.

Prototyping: Strengths

1. Customers can see the system requirements as they are being gathered
2. Developers learn from customers
3. A more accurate end product
4. Unexpected requirements accommodated
5. Allows for flexible design and development
6. Steady, visible signs of progress produced
7. Interaction with the prototype stimulates awareness of additional needed functionality.

Prototyping: Weaknesses

1. Tendency to abandon structured program development for code-and-fix development


2. Bad reputation for quick-and-dirty methods
3. Overall maintainability may be overlooked
4. The customer may want the prototype delivered
5. Process may continue forever (scope creep).

When to use Evolutionary Prototyping

1. Requirements are unstable or have to be clarified


2. At the requirements clarification stage of a waterfall model
3. Develop user interfaces
4. Short-lived demonstrations
5. New, original development
6. With the analysis and design portions of object-oriented development.

Exercise

At what stage of a system development project (for example, feasibility study, requirements
analysis, etc.) would a prototype be useful as a means of reducing the following uncertainties?

(a) There is a proposal that the senior managers of an insurance company have personal access to
management information through an executive information system installed on personal
computers located on their desks. Such a system would be costly to set up and there is some
doubt about whether the managers would actually use the system
A prototype could be useful as part of the feasibility study. A mock-up of an executive information
system loaded with current management information could be set up manually and then be tried out
by the managers to see how easy and useful they found it.
(b) A computer system is to support sales office staff taking phone calls from members of the
public enquiring about motor insurance and giving quotations over the phone
A prototype could be used to assist in the design of the user dialogues. Structured approaches like
SSADM often allow for prototypes for this purpose as part of requirement specification.
(c) The insurance company is considering implementing the telephone sales system using the system
development features supplied by Microsoft Access. They are not sure, at the moment, that it can
provide the kind of interface that would be needed and are also concerned about the possible
response times of a system developed using Microsoft Access

A prototype of the most response-critical transactions could be made at the physical design stage to
see whether Microsoft Access could produce software that gave a satisfactory performance.
4. The Spiral Model

Each cycle involves the same sequence of steps as the waterfall process model

Adds risk analysis, and RAD prototyping to the waterfall model.

Spiral Quadrant I
Determine objectives, alternatives and constraints

Objectives: functionality, performance, hardware/software interface, critical success factors, etc.

Alternatives: build, reuse, buy, sub-contract, etc

Constraints: cost, schedule, interface, etc.

Spiral Quadrant II
Evaluate alternatives, identify and resolve risks

Study alternatives relative to objectives and constraints

Identify risks (lack of experience, new technology, tight schedules, poor process, etc.)

Resolve risks (evaluate if money could be lost by continuing system development).

Spiral Quadrant III


Develop next-level product

Typical activites:

Create a design

Review design

Develop code

Inspect code

Test product.

Spiral Quadrant IV
Plan next phase

Typical activities

Develop project plan

Develop configuration management plan

Develop a test plan

Develop an installation plan.

Spiral Model Strengths

1. Provides early indication of insurmountable risks, without much cost


2. Users see the system early because of rapid prototyping tools
3. Critical high-risk functions are developed first
4. The design does not have to be perfect
5. Users can be closely tied to all lifecycle steps
6. Early and frequent feedback from users
7. Cumulative costs assessed frequently

Spiral Model Weaknesses

1. Time spent for evaluating risks too large for small or low-risk projects
2. Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive
3. The model is complex
4. Risk assessment expertise is required
5. Spiral may continue indefinitely
6. Developers must be reassigned during non-development phase activities
7. May be hard to define objective, verifiable milestones that indicate readiness to proceed through
the next iteration.

When to use Spiral Model?


1. When creation of a prototype is appropriate

2. When costs and risk evaluation is important


3. For medium to high-risk projects
4. Long-term project commitment unwise because of potential changes to economic priorities
5. Users are unsure of their needs
6. Requirements are complex
7. New product line
8. Significant changes are expected (research and exploration).
5. Incremental delivery

Rather than deliver the system as a single delivery, the development and delivery is broken down
into increments with each increment delivering part of the required functionality.

User requirements are prioritised and the highest priority requirements are included in early
increments

Once the development of an increment is started, the requirements are frozen though
requirements for later increments can continue to evolve.

Incremental development
Define outline
requirements

Develop system
increment

Assign requirements
to increments

Valida te
increment

Design system
architectur e

Integ rate
increment

Validate
system
Final
system

System incomplete

Incremental Model: Strengths


1. Develop high-risk or major functions first
2. Each release delivers an operational product
3. Customer can respond to each build
4. Uses divide and conquer breakdown of tasks
5. Lowers initial delivery cost
6. Initial product delivery is faster
7. Customers get important functionality early
8. Risk of changing requirements is reduced.

Incremental Model: Weaknesses

1. Requires good planning and design


2. Requires early definition of a complete and fully functional system to allow for the definition
of increments
3. Well-defined module interfaces are required (some will be developed long before others)
4. Total cost of the complete system is higher.

When to use the Incremental Model


1. Risk, funding, schedule, program complexity, or need for early realization of benefits.
2. Most of the requirements are known up-front but are expected to evolve over time
3. A need to get basic functionality to the market early
4. On projects which have lengthy development schedules
5. On a project with new technology.

6. Rapid Application Development (RAD) Model

Requirements planning phase - a workshop utilizing structured discussion of business problems

User description phase automated tools (e.g., Blueprint, Bright Green Projects) capture
information from users

Construction phase productivity tools, such as code generators, screen generators, etc. inside a
time-box. (Do until done)

Cutover phase - installation of the system, user acceptance testing and user training

RAD Strengths

1. Reduced cycle time and improved productivity with fewer people means lower costs
2. Time-box approach mitigates cost and schedule risk
3. Customer involved throughout the complete cycle minimizes risk of not achieving customer
satisfaction and business needs
4. Focus moves from documentation to code.
5. Uses modeling concepts to capture information about business, data, and processes.

RAD Weaknesses

1. Accelerated development process must give quick responses to the user


2. Risk of never achieving closure
3. Hard to use with legacy systems
4. Requires a system that can be modularized
5. Developers and customers must be committed to rapid-fire activities in an abbreviated time
frame.

When to use RAD?


1. Reasonably well-known requirements
2. User involved throughout the life cycle
3. Project can be time-boxed
4. Functionality delivered in increments
5. High performance not required
6. Low technical risks
7. System can be modularized

Selection of a life-cycle approach

Availability of users: Where the software is for the general market, then the identifiable users can
be quizzed about their needs.

Safety-critical systems: Where safety and reliability are essential, this might justify the additional
expense of a formal specification.

Specialized techniques:

For example, expert system shells and logic-based programming

languages have been invented to expedite the development of knowledge-based systems.

Imprecise requirements: Uncertainties or a novel hardware/software platform mean that a


prototyping approach should be considered.

If the environment in which the system is to be implemented is a rapidly changing one,


then serious consideration would need to be given to incremental delivery.

Structure vs. Speed of Delivery

The principle behind structured methods such as SSADM (structured systems analysis and design
method) is get it right for the first time.

Some customers like to get working applications delivered quickly and at less cost such as RAD
(may view the structured methods as unnecessarily bureaucratic and slow).

Agile Methods

Speed up or bypass one or more life cycle phases

Usually less formal and reduced scope

Used for time-critical applications

Used in organizations that employ disciplined methods

Agile software development

It is a group of software development methods in which requirements and solutions evolve


through collaboration between self-organizing, cross-functional teams.

It promotes adaptive planning, evolutionary development, early delivery, continuous


improvement, and encourages rapid and flexible response to change.

The Agile Manifesto

The Agile Manifesto is based on 12 principles:


1. Customer satisfaction by rapid delivery of useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity-the art of maximizing the amount of work not done-is essential
11. Self-organizing teams
12. Regular adaptation to changing circumstance

Agile Software Development Methods


1. Lean software development

2. Extreme Programming (XP)


3. Dynamic Systems Development Method (DSDM)
4. Agile Modeling
5. Agile Unified Process (AUP)
6. Crystal Clear
7. Crystal Methods
8. Feature Driven Development (FDD)
9. Graphical System Design (GSD)
10. Kanban (development)
11. Scrum
12. Velocity tracking

Lean Software Development

It is a translation of lean manufacturing and lean IT principles and practices to the


software development domain.

Adapted from the Toyota Production System.

The term lean software development originated in a book by the same name, written by
Mary Poppendieck and Tom Poppendieck.

Seven Principles of LSD


1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in

7. See the whole

LSD: Eliminate Waste

Everything not adding value to the customer is considered to be waste .

This includes:

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 be able to eliminate waste, one should be able to recognize it.

LSD: Amplify Learning

Software development is a continuous learning process with the additional challenge of


development teams and end product sizes.

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 endusers and getting their input.

The learning process is sped up by usage of short iteration cycles each one coupled with
refactoring and integration testing.

LSD: 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.

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 technologybounded decisions.

LSD: Deliver as Fast as Possible

The sooner the end product is delivered without considerable defect, 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.

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.

The just-in-time production ideology could be applied to software development, recognizing its
specific requirements and environment.

LSD: 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.

The lean approach favors 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. In software
development, 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. The developers should be given access
to the customer; the team leader should provide support and help in difficult situations

LSD: 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.

One of the healthy ways towards integral architecture is refactoring. The more features are added
to the System, the more loose the starting code base for further improvements.

Repetitions in the code are signs for bad code designs and should be avoided.

LSD: 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 organisations 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.

Reference Book:

Craig Larman and Bas Vodde, Practices for Scaling Lean & Agile Development: Large,
Multisite, and Offshore Product Development with Large-Scale, Pearson, 2010.

Lean Thinking

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.

Extreme Programming - XP

For small-to-medium-sized teams developing software with vague or rapidly changing


requirements

Coding is the key activity throughout a software project

Communication among teammates is done with code

Life cycle and behavior of complex objects defined in test cases again in code

XP Practices (1-12)
1. Planning game determine scope of the next release by combining business priorities and
technical estimates
2. Small releases put a simple system into production, then release new versions in very short
cycle
3. Metaphor all development is guided by a simple shared story of how the whole system
works
4. Simple design system is designed as simply as possible (extra complexity removed as soon
as found)
5. Testing programmers continuously write unit tests; customers write tests for features

6. Refactoring programmers continuously restructure the system without changing its


behavior to remove duplication and simplify
7. Pair-programming -- all production code is written with two programmers at one machine
8. Collective ownership anyone can change any code anywhere in the system at any time.
9. Continuous integration integrate and build the system many times a day every time a task
is completed.
10. 40-hour weeks work no more than 40 hours a week as a rule
11. On-site customer a user is on the team and available full-time to answer questions
12. Coding standards programmers write all code in accordance with rules emphasizing
communication through the code

XP is extreme because

Commonsense practices taken to extreme levels

If code reviews are good, review code all the time (pair programming)

If testing is good, everybody will test all the time

If simplicity is good, keep the system in the simplest design that supports its current functionality.
(simplest thing that works)

If design is good, everybody will design daily (refactoring)

If architecture is important, everybody will work at defining and refining the architecture
(metaphor)

If integration testing is important, build and integrate test several times a day (continuous
integration)

If short iterations are good, make iterations really, really short (hours rather than weeks)

Limitations of XP

There is a reliance on high-quality developers which makes software development vulnerable if


staff turnover is significant.

Even where staff retention is good, once an application has been developed and implemented,
the tacit, personal, knowledge of the system may decay.

This might make it difficult, for example, for maintenance staff without documentation to
identify which bits of the code to modify to implement a change in requirements.

Having a repository of comprehensive and accurate test data and expected results may not be as
helpful as might be expected if the rationale for particular test cases is not documented.

For example, where a change is made to the code, how do you know which test cases
need to be changed?

Some software development environments have focused on encouraging code reuse as a means
of improving software development productivity.

Such a policy would seem to be incompatible with XP.

Assignment

A travel agency needs software for automating its book-keeping activities. The set of activities to
be automated are rather simple and are at present being carried out manually. The travel agency
has indicated that it is unsure about the type of user interface which would be suitable for its
employees and its customers.

What SDLC models will you suggest for developing this software?

In the given case, a prototyping model would be appropriate for developing the user interface
part of the software.

For the other parts, a waterfall model would be appropriate assuming that the programmers are
experienced in developing similar software products.

Case: Customizing a Product

Assume that a software organization development has been asked to carry out a feasibility study
to develop the payroll package for Nalanda College.

The development organization plans to develop the software by customizing one of its existing
products.

What are the main steps through which the project manager of the organization would carry out
the feasibility study?

Nalanda College: feasibility study


1. Discuss with stakeholders and understand the important features that the pay roll software
needs to support.
2. Estimate the changes that have to be made to the existing software to support the features
identified in Step 1.
3. Estimate the cost to customize the existing software based on the estimates made in Step 2.
Also determine the time required to carry out the changes.
4. Estimate all other costs, including those for installation, training, feasibility study, project
management, office overheads, etc.

5. Arrive at the total cost of the software by adding the expected profit to the sum of the costs
computed in steps 2, 3 and 4.
6. Check with the college authorities if they agree with the estimated cost and duration for
completion of the project. Based on their response, make a decision to go ahead with the project,
otherwise abandon it.

Stakeholders

These are people who have a stake or interest in the project. Their early identification is important as
you need to set up adequate communication channels with them.

Stakeholders can be categorized as:


Internal to the project team
External to the project team but within the same organization
External to both the project team and the organization

External stakeholders may be customers (or users) who will benefit from the system that the
project implements.

They may be contractors who will carry out work for the project. The relationship here is
usually based on a contract.

Project managers can sometimes miss an important stakeholder group, especially in unfamiliar
business contexts. These could be departments supplying important services that are taken for
granted.

Given the importance of coordinating the efforts of stakeholders, the recommended practice is
for a communication plan to be created at the start of a project

Assignment

Identify the stakeholders in the Nalanda College payroll project.

Nalanda College payroll: stakeholders

Major stakeholders would include:


the finance department;
the human resources department, who would need to supply most of the employee details
needed;
heads of departments, who would need to submit details of hours worked for part-time staff;
staff, who would naturally be concerned that they are paid correctly;
software and hardware vendors.

One group of stakeholders that might not be readily identified at first is the local government
authority and its staff. It might seem strange to list the people who used to do the job, but who
are no longer required. The project manager's job will be made a lot easier if their cooperation
and help can be obtained. The project manager would do well to sound out tactfully how the local
authority staff feel about losing this work.

It could be that they are pleased to be short of the workload and hassle involved! Arrangements
that take into account existing local authority staff might be possible.

For example, if the college needs to recruit new staff to deal with payroll, it might
smoothen things to give the job to a member of the local authority staff who already deals
with this area.

Identify high-level project risks

The greater the uncertainties at the beginning, the greater the risk for the project to be
unsuccessful.

Once we recognize an area of uncertainty we can take steps to reduce its uncertainty.

Product uncertainty: How well are the requirements understood?

Process uncertainty: The project under consideration might be the first where an
organization is using a new application-building tool.

Resource uncertainty: The main area of uncertainty here is likely to be the availability of
staff of the right ability and experience.

Case

Nalanda College has identified as a risk the possibility that no suitable payroll package would be
available on the market.

What other risks might be inherent in the Nalanda College payroll project?

conflict of views between the finance and personnel departments;

lack of staff acceptance for the system, especially among personnel staff;

lack of cooperation by the local authority that used to carry out payroll work;

lack of experience with running payroll at the college, leading to errors and delays in
processing;

lack of administrative computing expertise at the college;

possible inadequacy of the chosen hardware;

changes to the payroll requirements.

Exercise

Assume that an external agency is offering an off-the-shelf solution to the Nalanda College Payroll
project.

Possible user resistance could be identified as a risk to an annual maintenance contracts project.
Would you classify this as a product, process or resource risk or some other?

The user staff could be regarded as a project resource. It may be appropriate to add a fourth
category of risk - those belonging to the environment in which the system is to be implemented.

Setting Objectives

Among all these stakeholders are those who actually own the project. They control the financing
of the project. They also set the objectives of the project. The objectives should define what the
project team must achieve for project success.

Informally the objectives could be written as a set of statements following the opening words 'the
project will be a success if. ...

SMART objectives
Specific:

Effective objectives are concrete and well defined. Vague aspirations such as 'to

improve customer relations' are unsatisfactory.


Measurable: Ideally there should be measures of effectiveness which tell us how successful the
project has been.
Achievable: It must be within the power of the individual or group to achieve the objective.
Relevant: The objective must be relevant to the true purpose of the project.
Time constrained: There should be a defined point in time by which the objective should have
been achieved.

Exercise

Bearing in mind the above discussion of objectives, comment on the appropriateness of the
wording of each of the following 'objectives' for software developers:
(i) to implement the new application on time and within budget;
(ii) to implement the new software application with the fewest possible software errors that might
lead to operational failures;
(iii) to design a system that is user-friendly;
(iv) to produce full documentation for the new system.

Exercise: Defining objectives


(i)

to implement the new application on time and within budget:

Deadline and budget constraints normally have to be set against the scope
and the quality of the functions to be delivered.

For example, if the deadline were not achieved, would the customer rather
have the full set of functionality at a later date, or an essential sub-set of the
functionality on the deadline date?

(ii) to implement the new application with the fewest possible software errors'

It is not precise. Removing errors requires effort and hence money. Can
developers spend as much money and time as they like if this reduces errors?

(iii) to design a system that is user-friendly:

What does 'user-friendly' really mean? How is it measured? Normally 'ease


of use' is measured by the time it takes for a beginner to become proficient
in carrying out standard operations.

(iv) to produce full documentation for the new system:

What does 'full documentation' mean? A list of the types of document to be


produced, perhaps with an indication of the content layout, would be more
useful.

ERP vs Other Softwares

ERP Project Management Triangle

Project management is the glue that holds the ERP project together.

Any change to one side of the triangle may require a change to one or more sides.

The role of the ERP project manager is one of the most exciting yet risky jobs in an
implementation.

To be successful one must be prepared to work long hours in a highly charged environment.

ERP Implementation Challenges

ERP systems are continuously changing and evolving (to provide the organization with a new way
of looking at business processes and decision making)

Organizations are also continuously changing (to match their environments)

ERP system implementations are generally very complex, time consuming, resource intensive,
and impact heavily on the organization

Therefore, before implementing ERP, an organization has to plan and understand the life cycle of
ERP systems

Choices for ERP Implementation

An organization has two choices when implementing ERP:

change business processes to match the softwares functionality

modify the ERP software

The consequences of selecting either option have a long-term impact on the organization in terms
of its performance of its employees, customers, and other stakeholders.

This is not an easy decision

A wrong decision can bring down the entire organization temporarily

A right decision can reap enormous benefits

A good understanding of the ERP technology and implementation process can significantly
improve efficiency and effectiveness of the organizations' business processes.

ERP Implementation Choices

In developing the business case for an ERP implementation one must make a decision on the
number of modifications to be made to address business requirements.

The "chocolate" implementation (to-be) with considerable modifications to the ERP software
package

The "vanilla implementation (as-is) with modification of the business processes

Chocolate (To-be) Implementation

Better user acceptance because the package has been customized based on user requirements

Increased chances of success

Can increase the investment in the system and introduce higher implementation risk

Missing best practices or leading practices of the business processes in their software.

Future upgrades to the ERP system become cumbersome and expensive.

Every time when an organization has to upgrade the ERP system needs special IT support staff

Uncertainty on the performance.

Vanilla (As-is) Implementation

The embedded business processes follow industry best practices

The ERP vendor upgrades their system on a regular basis, adding functionality, fixing
problems, and generally keeping the product current with the ever changing technology
innovations to remain competitive.

Disruptions can occur during the implementation with the functioning of the organization.

Employees, business partners, and clients will have to be retrained in the new business processes
(in addition to the ERP system).

Can generate resistance from the users, adding to the training expense for the implementation.

ERP Life Cycle

Understanding an ERP system life cycle gives an idea on the long-term investment in an ERP
system

The key to a successful implementation is to use a proven methodology

When a system implementation does not have a well-defined methodology, deadlines will likely
be missed, budgets overspent, and functionality will not meet the client's needs and requirements

ERP system implementations are very risky, and using a well-defined project plan with a proven
methodology will assist in managing those risks

ERP Project Implementation Lifecycle


1. Pre-evaluation screening
2. Package evaluation
3. Project planning phase
4. Gap analysis
5. Reengineering
6. Customization
7. Implementation team training
8. Testing
9. End-user training
10. Going live
11. Post implementation
12. Software / Vendor Selection

From the 1960s through the early 1990s many organizations were very capable of developing an
information system application in-house.

The development time was not lengthy and the systems developed were certainly not as complex.

It is very different today. Most organizations lack the skill sets and desire to spend the time and
money developing an ERP system "in house."

Most organizations today chose to purchase ERPs on the market.

Selection of a vendor-developed ERP system

The selection of a vendor-developed ERP system is a challenging job because the organization has
to find both a system that is most appropriate for its operational needs and a vendor to become
a "partner" for quite some time.

Before selecting a vendor, the organization must carefully evaluate its current and future needs
in enterprise management systems.

The assessment must look at the industry that the organization belongs to and the functional
areas that the ERP application will be supporting.

In addition it must review the organization's existing hardware, network, and software
infrastructure, and finally the resources (money and people commitment) available for the
implementation.

1. Pre-evaluation screening

Eliminate those packages that are not at all suitable for the companys business processes.

Limit the number of packages that are evaluated to less than 5.

One can zero in on the few best package by vendor research.

2. Package Evaluation

Once a package is purchased, it is not an easy task to switch to another one.

So it a 'do it right the first time' proposition and there is no room for error.

Remember that no package is perfect.

Get a system that has the least number of differences.

Find a package that is flexible enough to meet company's needs

The package could be customized to obtain a 'good fit'.

Vendor Evaluation

The vendor may be evaluated on the following:

business functions or modules supported by their software

features and integration capabilities of the software

financial viability of the vendor as well as length of time they have been in business

licensing and upgrade policies

customer service and help desk support

total cost of ownership

IT infrastructure requirements

third-party software integration

legacy systems support and integration

consulting and training services

future goals and plans for the short and long term

Vendor Research
Other businesses using the vendor
The vendor's financial position
The vendor's implementation philosophy and support issues
The hardware and software infrastructure used to support the ERP
The vendor's direction and currency of software
The vendor's release and upgrade strategies
The vendor's user-base involvement in defining future functional changes
The vendor's development and maintenance resources

3. Project Planning Phase

This phase will decide when to begin the project, how to do it and when the project is to-be
completed.

The organizational resources that will be used for the implementation effort are decided and the
people who are supposed to head the implementation are identified.

Plan what to do in case of contingencies; how to monitor the progress of the implementation,
what control measures should be installed and what corrective actions should be taken when
things get out of control.

Usually, a committee constituted by the team leaders of each implementation group, do the
project planning.

It will be headed by the ERP in-charge (usually the CIO or COO) and will meet periodically
(during the entire implementation lifecycle) to review the progress and chart the future
course of action.

4. Gap Analysis

This is the process through which companies create a complete model of where they are now and
where they want to-be headed.

The trick is to design a model, which both anticipates and covers any functional gaps.

It has been estimated that even the best ERP package, custom tailored to a company's needs,
meets only 80% of the company's functional requirements.

The remaining 20% presents a problematic issue for the company's BPR.

One of the affordable, but painful, solution is by altering the business to 'fit' the ERP package.

A company can simply agree to live without a particular function (the cheap but annoying
solution).

Other solutions include:


1. Pinning your hopes on an upgrade (low-cost but risky)
2. Identifying a third-party product that might fill the gap (hopefully it also partners with the
packages, keeping interfacing to a minimum)
3. Designing a custom program
4. Altering the ERP source code (the most expensive alternative; usually reserved for missioncritical installations)

5. Reengineering

In ERP implementation settings, reengineering has two different connotations.

The first connotation is use of ERP to aid in downsizing efforts.

The second use of the word reengineering in the ERP field refers to the BPR approach

But, companies cannot just shut down their operations while the mapping processes take place.

Hence, a prototype of the actual business processes the company is used.

The prototype allows for thorough testing of the "to-be" model in a controlled
environment.

As the ERP consultants configure and test the prototype, they attempt to solve any
logistical problems inherent in the BPR before the actual go-live implementation.

6. Customization

Increases user acceptance

Increases competitive advantage

Missing best practices

Shows inflexibility of the organization

Increased costs

Project delays

Uncertain performance

Up gradation issues

7. Implementation Team Training

An effective ERP implementation team with clear goals is the foundation of a successful
implementation project.

Its important to build an internal team that includes the people who helped select the ERP, along
with an executive sponsor and representation from across the enterprise, as well as other senior
management and internal leaders.

So, it is very vital that the company recognizes the importance of this phase and selects employees
with the right attitude, who are willing to change, learn new things and are not afraid of
technology-and good functional know ledge.

8. Testing

This is the phase were the system that is being implemented is tested for any problems, bugs,
errors, etc.

This is the phase where you try to break the system.

system overloads

multiple users logging on at the same time with the same query

users entering invalid data

hackers trying to access restricted areas

The test cases must be designed specifically to find the weak links in the system and these bugs
should be fixed before going live.

9. Going live

This is the phase where ERP is made available to the entire organization.

On the technical side, the work is almost complete where data conversion is done, and
databases are up and running.

On the functions side, the prototype is fully configured and tested and ready to go
operational.

The system is officially proclaimed operational, even though the implementation team must have
been testing it and running it successfully for some time.

Once the system is 'live' the old system is removed and the new system is used for doing business.

10. End-User Training

This phase actually starts much before the system goes live.

The employees who are going to use the new system are identified, their current skills are
noted and they are divided into groups, based on the current skill levels. Each group is
then given training on the new system.

The training sessions should give the participants an overall view of the system and how each
person's actions affect the entire system.

In addition to these general topics, each employee is trained on the job or tasks that he/
she is supposed to perform once the system goes live.

11. Post Implementation: Operation and Maintenance

Once the implementation is over the vendors and the hired consultants will go.

To reap the full benefits of the ERP system, the system should get enterprise-wide
acceptance.

There should be enough employees who are trained to handle the problems that might
crop up.

There should be people within the company who have the technical prowess to make the
necessary enhancements to the system, as and when required.

The system must be upgraded as and when new versions or new technologies are introduced.

Instead of going in for upgrade as and when a new version is announced by the vendor,
the organization should first analyze the costs and benefits.

The organization should think in terms of the incremental benefits of the new enhancements, as
with any upgrade or enhancements, there will be a lot of other aspects, like user training, that
have to be considered.

Operations and Post-implementation

Going live ("Go-live") is one of the most critical points in a project's success. A lot of time and
resources have been spent to get to this point.

In assessing an ERP project's readiness for Go-live it is vital to focus the efforts of the teams to
ensure that task and activities are completed before going live. This allows project management
to address any outstanding issues that may jeopardize the Go-live date.

This involves a readiness process that needs to include as many team members and appropriate
users and managers as possible because it helps the overall organization understand that the
implementation is near and that changes will be taking place.

ERP Stabilization

Stabilization is the time from Go live to about 90 days after, or until the number of issues and
problems has been reduced.

Many ERP implementations have turned into disastrous endeavors during or after the Go-live
stage.

FoxMeyer Drug actually collapsed during the stabilization stage, following SAP implementation,
in late 1990s and filed a $500 million lawsuit against SAP/R3.

An effective response to stabilization issues will determine how well the system is accepted by
the end-users and management.

Resource Requirements

Managing Sources of ERP Implementation Risk

Project feasibility studies typically provide estimate of financial benefits, qualitative benefits,
implementation costs, target milestone and completion dates, and staffing levels.

Only rarely, however, do they deal frankly with the risks of late delivery, cost overruns, or the
possibility of outright failure to deliver a working system.

Implementation Risk Factors


1. Project size.

The larger the project in terms of budget, staffing levels, duration, and number of
departments affected, the greater the risk.

2. Experience with the technology.

New technology projects are intrinsically more risky than are projects that use familiar
technologies. By hiring consultants with expertise in those technologies, a company can
potentially reduce the risk associated with unfamiliar technologies, but hiring experts is
not a cure-all.

3. Requirements volatility.

For some projects the nature of the task fully and clearly defines what is required of
project outputs. Other projects do not have such convenient characteristics; their
requirements are difficult to determine and tend to evolve throughout the project.