PROJECT VS OPERATION MANAGEMENT

PROJECT MANAGEMENT OPERATION MANAGEMENT

Projects are temporary in nature. It help the It is an ongoing organizational function that
business to meet organizational goals and to performs activities to produce products or
respond quickly and easily against any change. supply services

Changes after any project management is
significant.
Projects are unique in nature.
Here resources are transient.
It is a goal oriented management
Changes after operation management are
small and evolutionary.
Operations are repetitive in nature.
Here resources are stable.
It is role oriented management

It is an attempt to balance performance, time In this case performance, time and budget are
and budget usually fixed and managed.
PMO Functions
Augment Mentor Consult
Fill the gap Here PMO Through this
between team personnel work process the PMO
resources by together with the will provide
providing human project personnel occasional
resources to the to successful problem solving
required places. completion of any guidance /ideas to
task. the team.
The PMO should establish guidelines for company-
wide competencies, project- specific skills, and
situational crisis management tools. These
guidelines are used when it is determined that
PMO personnel will be involved in recovery of a
project.

The PMO and the project team will jointly agree if a

mentoring. consulting, or augmenting relationship
will be useful and or necessary.
Enterprise environmental factors
Organizational culture & structure

Governmental or industry standards

Infrastructure

Human resources

Personnel Administration
Organizations work authorization system

Marketplace conditions

Stakeholder risk tolerance

Commercial database

Project management information system

Role Of Project Manager
And
Competences Of Software Project Manager,
 Technical

Transactio Transform
nal ational
 Project Project Project Personnel
Planning organization staffing administration

Contract Technical Project Communicatio

administration management administration n Management

Materials Performance
Client relations Job closeout
management assurance
Plan Schedule Control Staff Motivate

-Tasks and -Continuous -Acquire -

subtasks -List of dates of monitoring and skilled, Review/evaluat
project events analysis (e.g. knowledgeable e team and
using Earned team individuals
-Synchronized Value
with the project Management) with
schedule compatible
-Help develop
-Supported by personalities
individuals
the Project Plan and
-Shows how career goals
complementary
each event will skills
be achieved -Apply
-Done in corrective
action to -Engage team
-Done in collaboration -Resolve intra-
achieve plan to perform well
collaboration with all team conflicts
on project
with the team involved
 -Use of various estimation methods
Estimating -Use of Reference Class Forecasting

-Written expression (e.g. status reports. Proposals)

Communications -Presentation skills

-Ability to evaluate and direct the actions of individuals

Personnel Management and teams
-Labor law

-Awareness & response to the effects of culture(s)

Cultural sensitivity represented on the development team
-Sensitivity and response to value system differences

Negotiation collaboration -Obtain consensus among stakeholders

-Cost allocation, general and administrative and overhead

Accounting expenses
 SYSTEM DEVELOPMENT LIFE CYCLE

BIPLAB BISWAS, 9713156563

Requirement Analysis & Definition

Software Requirement Analysis

System Analysis and Design

Code Generation

Software Integration and verification

System verification and testing

Operation and Maintenance

 Easy to understand, easy to use.
Provides structure to inexperienced staff.
Milestones are well understood.
Sets requirements stability.
Good for management control (plan, staff,
track).
Works well when quality is more important
than cost or schedule.
 It does not allow for much reflection or revision.
Estimating time and costs with any degree of
accuracy (as the model suggests) is often extremely
difficult.
customers don't really know what they want up-front
Designs that look feasible on paper turn out to be
expensive or difficult in practice.
re-design destroys the clear distinctions between phases of
the traditional waterfall model
a clear division of labor between, say, "designers",
"programmers" and "testers is neither realistic nor efficient
in most software firms
These regions are:
The planning task - to define resources, responsibilities,
milestones and schedules.

The goal determination task - to define the requirements and

constraints for the product and define possible alternatives.

The risk analysis task - to assess both technical and

management risks.

The engineering task - to design and implement one or more

prototypes or samples of the application.
 Emphasis on alternatives and constraints supports the reuse
of existing solutions.
Targets testing by treating it as a risk, which has to be
addressed. .
Estimates (budget and schedule) get more realistic as work
progresses, because important issues are discovered earlier.
It is more able to cope with the (nearly inevitable) changes
that software development generally entails.
Software engineers, who can get restless with protracted
design processes, can get their hands in and start working on
a project earlier.
 Only intended for internal projects (inside a company),
because risk is assessed as the project is developed. Hardly
suitable for contractual software development.
In case of contractual software development, all risk analysis
must be performed by both client and developers before the
contract is signed and not as in the spiral model.
Spiral model is risk driven. Therefore it requires
knowledgeable staff.
Suitable for only large scale software development. Does not
make sense if the cost of risk analysis is a major part of the
overall project cost.
 Generates working software quickly and early
during the software life cycle.
More flexible less costly to change scope and
requirements.
Easier to test and debug during a smaller
iteration.
Easier to manage risk because risky pieces are
identified and handled during its iteration.
Each iteration is an easily managed milestone.
 Each phase of an iteration is rigid and do not
overlap each other.

Problems may arise pertaining to system

architecture because not all requirements are
gathered up front for the entire software life cycle.
Professor Clifford Kettemborough, defines Rapid Application
Development as an approach to building computer systems
which combines Computer-Assisted Software Engineering
(CASE) tools and techniques, user-driven prototyping, and
stringent project delivery time limits into a potent, tested,
reliable formula for top-notch quality and productivity. RAD
drastically raises the quality of finished systems while reducing
the time it takes to build them.
 Users are actively involved in the development
It provides a better system to users, as users have
natural tendency to change their mind in specifying
requirements and this method of developing
systems supports this user tendency.
Since in this methodology a working model of the
system is provided, the users get a better
understanding of the system being developed.
Errors can be detected much earlier as the system is
mode side by side.
Quicker user feedback is available leading to better
solutions.
 Leads to implementing and then repairing way of
building systems.
Practically, this methodology may increase the
complexity of the system as scope of the system may
expand beyond original plans.
Customer could believe the prototype as the working
version.
 Developer also could make the implementation
compromises where he could make the quick fixes to
the prototype and make it as a working version.
Often clients expect that a few minor changes to the
prototype will more than suffice their needs. They fail
to realize that no consideration was given to the overall
quality of the software in the rush to develop the
prototype
Models Suitability
Waterfall -Fixed requirements.
-Work proceeds to completion in a linear manner.
-Without any time aggressiveness.
-It can not handle High Risks Project
Spiral -Large scale system and software.
-Level of Reliability is High.
-where reaction to Risks at each evolutionary level is required.
RAD -Time line is aggressive.
-Risk is not so high.
-Small to medium size projects.
Incremental -High technical risks.
-Time line is aggressive
The product life cycle is the concept that a
product goes through several stages in the
course of its life: market introduction, market
growth, market maturity and sales reduction. At
each stage, a product's marketing mix might
change, as will its revenue and profit profile
[Perrault-McCarthy, 1997].