4

● Core Process 5: Buld, Test and Integrate System Components

○ Continue programming (build)
○ Build use case by use case
○ Perform unit and integration test
Day 6 Activities
● Core Process 6: Complete System Testing and Deploy the system
○ Perform system functional testing
○ Perform user acceptance testing
○ Possibly deploy part system
First Iteration Recap
● This project was a 6 day iteration of small project
○ Most iterations are longer (2 to 4 weeks)
○ This project might be 2 iterations
○ Most projects have many more iterations
● End user need to be involved, particularly in day 1,2,3 and 6
● Days 4 and 5 involved design and programming concurrently
Ch 10 - Approaches to System Development
The System Development Life Cycle (SDLC)
● There are two general approaches to the SDLC
● Predictive Approach (methodology) to the SDLC
○ Waterfall model
○ Assumes the project can be planned in advance and that the information system can be
developed according to the plan
○ Requirements are well understood and/or low technical risk
● Adaptive Approach to the SDLC
○ Iterative model
○ Assumes the project must be more flexible and adapt to changing needs as the project
progresses
○ Requirements and needs are uncertain and/or high technical risk
● Most projects fall on a continuum between Predictive and Adaptive

Traditional Predictive SDLC

We could use predictive SDLC and adaptive SDLC both at same time so we shouldn’t choose one
methodology
Adaptive SDLC ex is my banner (uncertain and high technical risk) always lagging
● Have sequential Phases
○ Phases are related groups of development activities, such as planning, analysis, design,
implementation, and deployment these are the 5 main phases and it could be more than 5 + you could
work at two phases at same time or you could go back and adjust or edit
● Waterfall model
○ SDLC that assumes phases can be completed sequentially with no overlap or iteration
 5

○ Once one phase is completed, you fall over the waterfall to the next phase, no going back

Tradition IS Development Phases

Waterfall Predictive SDLC

Modified Waterfall with Overlapping Phases

● More flexibility, but still assumes predictive planning and sequential phases

Diamond is the decision point, this means here we stop and evaluate whether we are sure if we’re done or should we go back and
finalize. As you can see design started during working on analysis, this means you can work at both phase at same time
“overlapping phases”
Newer Adaptive SDLC
● Emerged in response to increasingly complex requirements and uncertain technological
environments
 6

● Always includes iterations where some of design and implementation is done from the beginning
● Many developers claim it is the only way to develop information systems
● Incremental development
● Completes portions of the system in small increments and integrated as the project progresses

A Generic Adaptive Approach

● Six Core Processes go across iterations
● Multiple Iterations as required

Methodologies
A Methodology includes a collection of techniques
that are used to complete activities and tasks,
including modeling, for every aspect of the project.
It guides us through phases & provides us every iteration in
SDLC

Methodologies, Models, Tools, and Techniques

● Model
○ An abstraction of an important aspect of the real world.
○ Makes it possible to understand a complex concept by focusing
only on a relevant part
○ Each model shows a different aspect of the concept
○ Crucial for communicating project information
Graphical models represents “input —> process —> output” in order to communicate between analyst and programmer so it
helps in communication between both
● In IS, some models are of system components that will be developed
● Other models are used to manage the
development process

● Tools —> models are created using tools, tools are

softwares
○ Software applications that assists
developers in creating models or
other components required for a
project (examples: Microsoft
Project, Visio, Access, Excel)
● Integrated Development Environment (IDE)
○ set of tools (more than one) that work
together to provide a comprehensive
development environment (Visual
Studio)
 7

Technique
A collection of guidelines that help an analyst complete an activity or task
Learning techniques is the key to having expertise in a field
It’s a concept/strategy/ principles that guides the system analyst activities/tasks

Agile Modeling Principles

● Agile Modeling (AM) – 12 Principles —> each methodology has some principle components
○ Agile means ‘ability to move quickly and easily’ and responding swiftly to change (being
able to respond fast to any changes in the system requirements)
○ A philosophy – build only necessary models that are useful and at the right level of detail

Agile Principles
● Develop software as the primary goal —> focus on system
○ Don’t get distracted by documentation or models
● Enable the next effort as your secondary goal
○ Be aware of next step versions or revisions
● Minimize your modeling activity —> use whatever you need, so don’t use what doesn’t add anything
○ Only build what helps move the project forward
● Embrace change and change incrementally —> small changes at a time
○ Take small steps that keep you on-track and that can be reversed if necessary
● Model with a purpose —> don’t use any graph that doesn’t add value
○ Model to understand
○ Model to communicate
● Build multiple models —> to look at systems from different point of views
○ Look at problems from different perspectives (user perspective, owner perspective)
● Build high-quality models and get feedback —> get feedback on every iteration & make modifications
● Focus on content rather than representation
○ Informal hand-drawn models are sometimes okay
○ Always focus on stakeholder needs
● Learn from each other with open communication
● Know your models and how to use them
● Adapt to specific project needs
● Maximize stakeholder ROI —> so we need to design the system in most efficient way to minimize cost &
maximize return
Example
 8

● A company is working on a project to come up with a competing product for MS Word, that
provides all the features provided by MS Word and any other features requested by the marketing
team. The final product needs to be ready in 10 months of time.

Traditional Waterfall Methodology (relying on planning)

● At a high level, the project teams would spend 15% of their time on gathering
requirements and analysis (1.5 months)
● 20% of their time on design (2 months)
● 40% on coding (4 months) and unit testing
● 20% on System and Integration testing (2 months).
● At the end of this cycle, the project may also have 2 weeks of User Acceptance testing by
marketing teams.
● In this approach, the customer does not get to see the end product until the end of the
project, when it becomes too late to make significant changes + giving feedback
We divide 10 months among phases (multiple the % by number of months)

Agile methodology
● In the Agile approach, each project is broken up into several ‘Iterations’. (cycles)
● All Iterations should be of the same time duration (between 2 to 8 weeks).
● At the end of each iteration, a working product should be delivered.
● In simple terms, in the Agile approach the project will be broken up into 10 releases (assuming
each iteration is set to last 4 weeks). (10 iterations/columns)
● Rather than spending 1.5 months on requirements gathering, in Agile software development, the
team will decide the basic core features that are required in the product and decide which of these
features can be developed in the first iteration.
○ Usually in the first iteration they start with the basic core features then move on with the rest
iterations
● Any remaining features that cannot be delivered in the first iteration will be taken up in the next
iteration or subsequent iterations, based on priority.
● At the end of the first iterations, the team will deliver a working software with the features that
were finalized for that iteration.
● There will be 10 iterations and at the end of each iteration the customer is delivered a working
software that is incrementally enhanced and updated with the features that were shortlisted for
that iteration.

traditional Waterfall model

“Beck, Beedle, Van Bennekum, Cockburn, et al.
(2001) defined the agile philosophy as follows:
We are uncovering better ways of developing software
by doing it and helping others do it. Through this
work we have come to value:
1. Individuals and interactions over processes
and tools
2. Working software over comprehensive
documentation
3. Customer collaboration over contract
negotiation
4. Responding to change over following a plan
 9

5. That is, while there is value in the items on the right, we value the items on the left more.”

Agile Method

In every iteration we add more features but we work at all six

processes at once and build up. Where on the other hands the
traditional waterfall model works at one by one and doesn’t
move on to the next step until they’re fully done with what
they’re working on and they can’t go back to adjust

Example of agile method

 10

agile is flexible non agile is not flexible and can’t make changes
Agile size is small non agile is large
Agile adapt is flexible non agile is less flexible
Agile importance could share with other people and it is relying on involvement of people
Agile team size is small not more than 10
If requirement are not clear and certain we use agile
Agile developers are more plan oriented more technical oriented and outcome oriented.
 11

Advantages of Agile Methodology

● The customers are satisfied because after every cycle the working feature of the software is
delivered to them. So they could see every step their working on and changes could occur
● Customers can have a look of the working feature which fulfilled their expectations.
● If the customer has any feedback or any change in the feature then it can be accommodated in the
current release of the product. Edits and changes could easily happen
● In Agile methodology the daily interactions are required between the business people and the
developers.
● Changes in the requirements are accepted even in the later stages of the development.

Disadvantages of the Agile Methodology

● In Agile methodology the documentation is less.
● Sometimes in Agile methodology the requirement is not very clear hence it’s difficult to predict
the expected result.
● In few of the projects at the starting of the software development life cycle it’s difficult to
estimate the actual effort required.
● The projects following the Agile methodology may have to face some unknown risks which can
affect the development of the project.

The Unified Process (UP)

● The UP was the early leader in adaptive approaches
● UP and UML (Unified Modeling Language) were developed together
● UP Phases organize iterations into four primary areas of focus during a project
○ Inception phase – getting the project started
 12

○ Elaboration – understanding the system requirements

○ Construction – building the system (process 5)
○ Transitions – preparing for and moving to deploying the new system (process 6)
Unified Process (UP) – Phases
Objectives of each phase

Extreme Programming (XP)

● Takes the best practices of software development and extends them “to the extreme”
○ Focus intensely on proven industry practices
○ Combine them in unique ways to get better results
● XP Core Values
○ Communication
○ Simplicity
○ Feedback
○ Courage
● XP Practices
○ Planning – based on user stories
○ Testing – thorough testing at every step
○ Simple Designs – Agile modeling principles
○ Refactoring – redo and cleanup as you go
○ Small releases – turn over to user frequently
○ Forty-hour work week – don’t overload the developers
 20

The Ten Commandments of Computer Ethics

1. Thou shalt not use a computer to harm other people.
2. Thou shalt not interfere with other people’s computer work.
3. Thou shalt not snoop around in other people’s computer files.
4. Thou shalt not use a computer to steal.
5. Thou shalt not use a computer to bear false witness.
6. Thou shalt not copy or use proprietary software for which you have not paid.
7. Thou shalt not use other people’s computer resources without authorization or proper compensation.
8. Thou shalt not appropriate other people’s intellectual output.
9. Thou shalt think about the social consequences of the program you are writing or the system you are
designing.
10. Thou shalt always use a computer in ways that insure consideration and respect for your fellow human
Ch 11 - Project Planning & Project Management
Principles of Project Management:
The Need for Project Management → it increase rate of success of project
● Categories of project success
○ Successful projects – on time, within budget, meeting the scope of the project
○ Challenged projects – failure in one area
○ Failed projects – cancelled or not used
● Recent years have seen some improvement, but still 1/3 to 1/2 of projects are challenged or fail

The Need for Project Management

● Reasons for failure
○ Undefined project management practices .if we don’t have a good plan, no good team members, not
good in communication + no good tools + no good top management support
○ Poor IT management and poor IT procedures
○ Inadequate executive support for the project
○ Inexperienced project managers
○ Unclear business needs and project objectives
○ Inadequate user involvement
The Role of the Project Manager
● Project Management
○ Organizing and directing other people to achieve a planned result within a predetermined
schedule and budget
○ The processes used to plan the project and then to monitor and control it.
● Project Manager Responsibilities
○ Internal Responsibilities
■ Developing the project schedule
■ Recruiting and training team members
 21

■ Assigning work to teams and team members

■ Assessing project risks
■ Monitoring and controlling project deliverables and milestones
○ External Responsibilities
■ Reporting the project’s status and progress
■ Working directly with the client (the project’s sponsor) and other stakeholders
■ Identifying resource needs and obtaining resources
Project Manager & Project Stakeholders

Project Management Body of Knowledge (PMBOK)

Project Management Institute: www.PMI.org
PMBOK is organized into 10 knowledge areas:
● Project Integration Management—Integrating all the other knowledge areas into one seamless
whole (together)
● Project Scope Management—Defining and controlling the functions that are to be included in
the system as well as the scope of the work to be done by the project team what goal, what tool to use
what templates
● Project Time Management—Creating a detailed schedule of all project tasks and then
monitoring the progress of the project against defined milestones
● Project Cost Management—Calculating the initial cost/benefit analysis and its later updates and
monitoring expenditures as the project progresses
● Project Quality Management—Establishing a comprehensive plan for ensuring quality, which
includes quality control activities for every phase of a project establishing standards
● Project Human Resource Management—Recruiting and hiring project team members; training,
motivating, and team building; and implementing related activities to ensure a happy, productive
team
● Project Communications Management—Identifying all stakeholders and the key
communications to each; also establishing all communications mechanisms and schedules
 22

● Project Risk Management—Identifying and reviewing throughout the project all potential risks
for failure and developing plans to reduce these risks
● Project Procurement Management—Developing requests for proposals, evaluating bids,
writing contracts, and then monitoring vendor performance
● Project Stakeholder Management—Identifying and communicating with the stakeholders of the
new system as they affect and influence the project
Activities of Core Process 1:
● Identify the Problem and Obtain
Approval
Identify the Problem (Preliminary
investigation):
● IS Development Projects usually:
○ Respond to an opportunity
■ Strategic initiative
■ Something that
provides competitive
advantage
○ Resolve a problem
■ Operational issues keep coming up
■ User needs aren’t being met
○ Respond to an external directive (rules)
■ Legislation requires new form of reporting
■ Changes in tax laws or regulations
Steps in Problem Identification (Preliminary Investigation) and get approval we have to create a
case to represent it to to management so they can approve it
● Step 1: Understand the Problem or Opportunity. If we have a problem we need to understand it
and analyze it and look at cause
● Step 2: Define the project scope and constraints. What the main objective what are the limitations
● Step 3: Quantify Project Approval Factors : Project justification estimate cost of project estimate
the time, so we can have solid numbers that we can present to top management
● Step 4: Determine Project Risk and Feasibility we should consider risk, the factors that may
influence the success of project
● Step 5: Review with Client and Obtain Approval (Present Results and Recommendations to
Management)
Steps in Problem Identification (Preliminary Investigation)
● Step 1: Understand the Problem or Opportunity.
○ You cannot solve a problem until you understand it
and you cannot understand it until you analyze it. This means identifying the causes, the
main reasons behind the problem so we can come up with a solution

● Techniques used for Problem Analysis:

1. 5-Whys and So What? Asking yourself why this problem what is the reasons
Ex. You have a small company to print poster an flyers and one customer didn’t
pay, then you ask yourself why they didn’t pay, answer is we were late, why we were late because
printer was late, why the printer is late, the problem is caused from the ink
2. A fishbone diagram, or Ishikawa diagram: a popular technique for investigating
causes and effects
Fishbone diagram, it provides us with the causes of the problem
3. Pareto chart
4. PIECES framework
 23

System constraint —> limitations

To be able to come up with a chart like this we need to
identify the problem and causes and effects

Ishikawa Diagram
● Graphical model used to identify, explore, and depict problems and the causes and effects of those
problems. It is often referred to as a cause-and-effect diagram or a fishbone diagram.
○ Problem at right (fish head)
○ Possible causes drawn as "bones" off main backbone
○ Brainstorm for 3-6 main categories of possible causes
We have members
contract default, the
problem is that many
customers they break
contract before end of
term, and on the left
are all possible causes

A sample of Cause-and-Effect Diagram

Problem on right “can not login” and on the

left they used the 5 why technique to get to the
root cause
 24

Pareto Charts:

● A Pareto chart is a histogram that can help you

identify and prioritize problem areas.
● Pareto analysis is also called the 80-20 rule,
meaning that 80 percent of problems are often due
to 20 percent of the causes.
It’s a bar chart with a line chart (combined). We create a
cumulative % for each problem, so we take the total
number and we divide each frequency by the total number.
The second point in the line chart represents the
cumulative of first to problems.
The manager would focus on most frequent problem

The PIECES Problem-Solving Framework

P: the need to improve performance (system performance “output or response time”
I: the need to improve information (and data) “input”
E: the need to improve economics, control costs, or increase profits “cost of system”
C: the need to improve efficiency of people and processes
S: the need to improve service to customers, suppliers, partners, employees, etc.
Steps in Problem identification (Preliminary Investigation)
● Step 2: Define the Project Scope and Constraints
○ Project scope: defining specific boundaries of the project. For example “payroll is not
being produced accurately versus overtime pay is not being calculated correctly for
production workers on the second shift at Doha plant” another example, the project scope
is to modify the account receivable system versus the project scope is to allow customers
to inquire online about account balance and recent transactions
■ You may define the project scope by creating a list of:
■ What it Must do? Should do? Could do? Won’t do? These questions will help
us to know the scope of the project
■ The list could be reviewed later in the analysis phase (e.g., system requirement
identification)
■ Project creep: increase in project scope without authorization.
Once we determine the scope we need to determine the requirements
● Constraint: a requirement, condition, or outcome that the system must satisfy or achieve.
● Three characteristics for constraints should be examined:
○ Present versus future. (e.g., must met as soon as the system is developed?)
○ Internal versus external (is it due internal requirements or external forces?)
○ Mandatory versus desirable (essential or desirable?).
○ Regardless of the type, all constraints should be identified as early as possible to avoid
future problems and surprises.

For example if we have urgent requirements coming from

government then its external and mandatory
A manager needs a certain export in certain format, they have the
report ready but they’ll like to see it in another format then its
internal and desirable
● System Vision Document: a document to help define the
scope of the new system
 25

○ Problem Description
■ What is the problem and idea for the solution?
○ System Capabilities
■ What are the capabilities the new system will have?
■ Helps define the scope
○ Business Benefits
■ The benefits that accrue to the organization
■ Tangible (in dollars) and intangible benefits
Business case
Example if you'd like to take a loan, you need to provide them with a
case “background info of your project”. This is more detailed than the
vision document
3. Quantify Project Approval Factors : Project justification
● Estimated Time for Completion
● Estimate cost for the project
● The anticipated benefits
● Estimated Cost for Development
● Anticipated Benefits from New System
○ Opening up new markets with new
services, products, or locations
○ Increasing market share in existing
markets
○ Enhancing cross-sales capabilities with
existing customers
○ Reducing staff by automating manual functions or increasing efficiency
○ Decreasing operating expenses, such as shipping charges for “emergency shipments”
○ Reducing error rates through automated editing or validation
○ Reducing bad accounts or bad credit losses
○ Reducing inventory or merchandise losses through tighter controls
○ Collecting receivables (accounts receivable) more rapidly
● Tangible “Dollar” Benefits
○ Used for Cost/Benefit Analysis--process of comparing costs and benefits to see whether
investing in a new system will be beneficial-- ex. Reducing costs
Cost\Benefit Analysis (very important in any project)
● Cost/benefit analysis
○ comparing costs and benefits to see if the net result is plus or minus
● Net Present Value (NPV)
○ the present value of dollar benefits and dollar costs of a particular investment
● Break-even Point
○ point in time at which benefits (revenue) and costs are equal
● Payback Period
○ the time period after which the dollar benefits have offset the dollar costs (period of payback
period to break-even point, the shorter the better)
● Tangible Benefit
○ a benefit that can be measured or estimated in terms of dollars
● Intangible Benefit
○ a benefit that accrues to an organization but that can’t be measured quantitatively or estimated
accurately
Examples of Intangible Benefits
● Increased levels of service (in ways that can’t be measured in dollars)
● Increased customer satisfaction (not measurable in dollars)
● Survival—need to do it to compete
● Need to develop in-house expertise (such as a pilot program with new technology)

Cost\Benefit Analysis
 26

● Use present value (after discount factor) for all dollar values
● Estimate the useful life of the system
● The NPV after 5 years is $1,713,097
● Payback Period is 2 years and 128 days
4. Determine Project Risk and Feasibility
● Determine the organizational risks and feasibility
○ How well does the new system fit the
organizational culture? Risk of negative impacts?
● Evaluate the technological risks and feasibility
○ Can the system be built by the team using technology needed? Training available?
● Assess the resource risks and feasibility
○ Are the needed resources available? Skilled people?
● Identify the schedule risks and feasibility
○ Can the system be built in the amount of time available? Fixed Deadline?
How much training is needed? Are we expecting them to use the system in most efficient way? Do we need experts?
Evaluate Feasibility
● Operational feasibility (user needs, requirements, expectations).
○ Will the solution fulfill the users’ requirements? To what degree? How will the
solution change the users’ work environment? How do users feel about such a
solution?
● Technical feasibility (hardware, software, technical resources)
○ Is the solution technically practical? Does our staff have the technical expertise to
design and build this solution?
● Economic feasibility (financial analysis tools)
○ Is the solution cost-effective?
● Schedule feasibility (acceptable completion date)
○ Can the solution be designed and implemented within an acceptable time period?
Feasibility Matrix

According to their
importance we assign
weights, just like
homework and exams.
We assign more weight
to the more important
task or feasibility
Based on experience
we assign scores for
every candidate
Ranking = .3*60
+.3*50+.3*95 = 60.5

We rank to find the best

solution to solve the
problem
 27

5. Review with Client and Obtain Approval

● Executive committee reviews and approves
● Board must review and approve for very large projects
● Involved stakeholders need to understand what is expected of them
● IS department needs to know what to do for staffing and support
● Whole organization should be made aware of the project and its importance
Activities of Core Process 2:
Plan and Monitor the Project (5 activities)
1. Establish the Project Environment
● Project manager must establish project
parameters (determine environment) and
the work environment:
○ Recording and
communicating—internal and
external
■ Who, what, when, and
how
○ Work environment
■ Workstations, software development tools (IDE), servers and repositories, office
and meeting space, support staff (you have to decide on the technical
enviornment and what methodology “waterfall or agile)
○ Process and procedures followed
■ Reporting and documentation, programming approach, testing, deliverables, code
and version control
● In other words, tailor and operationalize the
methodology being used
2. Schedule the Work
● Project manager must establish initial project schedule
and keep adjusting
○ Project Iteration Schedule (identify tasks)
■ The list of iterations and use cases or
user stories assigned to each iteration
(we use work breakdown structure)
○ Detailed Work Schedule
■ Within an iteration, the schedule that
lists, organizes, and describes the
dependencies of the detailed work tasks
■ As each iteration is finished, a detailed
work schedule is prepared for the next
iteration
■ The next detailed work schedule takes into account the changes necessary based
on feedback/progress
Use cases are scenarios ex. When you draw money, first we insert card then we put the pin…
● Developing Detailed Work Schedule takes three steps:
○ Develop a Work Breakdown Structure (WBS)
■ The list or hierarchy of activities and tasks used to estimate the work to be done
in a project or iteration
Under each phase we list the task, heading is phase, and the numbered subheadings are tasks
○ Estimate effort and identify dependencies
■ Task times
■ Tasks that must be completed before another task begins
■ Critical path--a sequence of tasks that can’t be delayed without causing the entire
project to be delayed
 28

There are different methods to estimate time, we take 3 estimates, then we ask experts about each task how long would it take
from there own experience. There are two types of people, optimistic who gives the nearest time, minimum period, and there are
people who worry a lot and give the max time
○
Create a schedule using a Gantt chart
■ Bar chart that portrays the schedule by the length of horizontal bars
superimposed on a calendar
○ Tasks for the Work Breakdown Schedule
○ There should be a way to recognize when the task is complete.
○ The definition of the task should be clear enough so you can estimate the amount of effort
required.
○ As a general rule for software projects, the effort should take one to five working days.
Schedule the Work:
Work Breakdown Structure (WBS) with Time Estimates and Notes

Breakdown tasks -> assign relationship-> assign duration

Under each phase we list the task, heading is phase, and the numbered
subheadings are tasks
Once we have the tasks and durations then we need the third piece of info
which is the relationship among these tasks, which is when we finish what
we start next

We need 3 information
- task name
- Duration
- Relationship

● Gantt Chart and PERT chart for

first iteration
○ Shows task, duration,
start date, predecessors,
and resources
○ Generates chart
graphically showing
dates, predecessors, tasks,
and critical path
Grantt chart is a bar chart (horizontal) against the
table. Predecessor is the task that comes before a
task you want to do. Meeting with marketing
depends on meeting with sales so after finishing
cell 2 we can start the meeting with market
Parallel activities don’t depend on each other we
could work on them at the same time (ex.activities
7,8,9)
 29

3. Staff and Allocate Resources

● Staffing activity tasks consists of 5 tasks:
○ Developing a resource plan for the project
○ Identifying and requesting specific technical staff
○ Identifying and requesting specific user staff
○ Organizing the project team into work groups
○ Conducting preliminary training and team-building exercises
Staffing and allocating resources is important after you create your plan/schedule
4. Evaluate Work Processes:
Retrospective
● Are our communication procedures adequate? How can they be improved?
● Are our working relationships with the user effective?
● Did we hit our deadlines? Why or why not?
● Did we miss any major issues? How can we avoid this in the future?
● What things went especially well? How can we ensure it continues?
● What were the bottlenecks or problem areas? How can we eliminate them?
You have to always monitor and evaluate the process. Any failure in meeting the project constraint this
means our project is not succcessful
5. Monitor Project Progress and Make Corrections
● Process to monitor and control project execution

To make up any delay we need to create this flow chart for it (solving the problem)
Monitor Project Progress and Make Corrections
● Sample Issues-Tracking Log

Or you could use the tracking log to monitor with details

Ch C - Project Management Techniques
● Chapter 11 focused on project management principles, which are a major portion of each of the first two core
processes: Identify the problem and obtain approval, and Plan and monitor the project
● This online chapter will extend the coverage of project management principles and will provide additional explanations
on several of the important project management techniques, including the use of Microsoft Project software
 30

● This chapter will explain cost/benefit analysis in more depth as well as explain two other financial measures: breakeven
point and return on investment

Calculating Financial Returns - Net Present Value

● The two basic concepts of net present value are (1) that all benefits and costs are calculated in
terms of today’s dollars (that is, present value) and (2) that benefits and costs are combined to
give a net value—hence, the name net present value
● Discount rate – the annual percentage rate that an amount of money is discounted to bring it to a
present value
● Discount factor – the accumulation of yearly discounts based on the discount rate

● NPV Calculation Example

n
● Discount factors F are usually looked up in tables rather than calculated
We need to calculate/find discount factor first
I: discount rate, n: number of years
● For RMO CSMS Project:

Calculating Financial Returns - Payback Period

● Payback period – the amount of time the system has to operate to repay the costs of building and
operating it
● In the example in Figure C-1, we use the time value of money (that is, the discount rate) and use
net benefits (that is, benefits minus operating costs)
● The year when the cumulative value becomes positive is the year in which payback occurs.

Calculating Financial Returns - Return on Investment (ROI)

● Return on investment – calculates a percentage return (like an interest rate) on the initial
investment
● Sometimes, ROI calculations are done by using values that include the discount factor
● At other times, ROI is done on purely a cash basis without considering the organization’s
assigned discount rate
 31

PERT/CPM Charts
● PERT/CPM chart is a network diagram with boxes that represent the tasks or activities of the
project and with connecting arrows that represent the sequence and dependencies between tasks
● PERT, which stands for Project Evaluation and Review Technique developed by the U.S.
Department of Defense to organize, monitor, and control very large, complex defense projects
● CPM, which stands for Critical Path Method, was developed independently
● In practice, the two techniques are combined
Microsoft Project is used to create this diagram

Title: Create Work Breakdown Structure (WBS) Work Breakdown Structure (WBS)
First Iteration of CSMS Project With Predecessor Information added

predecessor is the number of the task that should be complete before

the current task, ex. We couldn’t start task 5,6,7 until we finish 3,4.
Additionally this indicates that we can start 5,6,7 all at the same time

PERT/CPM chart - After identifying task dependencies

each task is a box and the arrows represents the relationships

PERT/CPM chart - Critical Path

● Early start time – the earliest time that a task can begin due to predecessor durations
● Late start time – the latest time that a task can start to maintain the schedule
● Slack time – the amount of time a task or leg of sequential tasks can be delayed without
impacting the project schedule
● Earliest finish - earliest time we finish a task
● Latest finish - delaying the finishing date if we have slack time