CS-868 Software Project Management

CS-868 Software Project Management
Lecture 1
•1
SOFTWARE PROJECT MANAGEMENT
CS-868 Software Project Management

MS-20
Brig Dr Muhammad Abbas
 Instructor Brig Dr Muhammad Abbas
 Email abbasamir@hotmail.com
m.abbas@ceme.nust.edu.pk
 Class Session Wed 5:30---8:30 pm
 Office Hours After class, via email, or by appointment
•3 •CSE-868 Software Project Management

Your Background
 Name
 Day Job or Equivalent
 Final Project
 Project Management Experience
 Industry Experience
 Optional: Any thing else
Evaluation Components
 Quizzes 5 10%
 Assignments 10%
 Project 10%
 Sessionals 30%
 Final 40%

Textbooks
•Required Textbooks
1.Information Technology Project Management, Schwalbe, Kathy, 8th
edition, Course Technology,
2. Rapid Development, McConnell, Steve, Microsoft Press, 1996, ISBN
1-55615-900-5.
•Recommended reading
1.PM BOK “A guide to Project Management Body of Knowledge”
2.Software Project Management - Bob Hughes -2nd Ed-1999
3.“Software Project Survival Guide”, Steve McConnell
•6
4.“Peopleware”, T. DeMarco and T. Lister
Software Project Management
Lecture 1

Sequence
 Introduction
 Project dimensions
 Project Management
 Rapid Development
 Classic Mistakes

Why Study Software Project Management?
 To understand the processes, tools,

techniques, and areas of knowledge needed to
successfully manage software projects.
•1-9
Introduction
 Software project management encompasses the knowledge,
techniques, and tools necessary to manage the development of
software products.
 This course module will discuss material that managers need to
create a plan for software development, using effective estimation
of size and effort, and to execute that plan with attention to
productivity and quality.
 Software project management is strictly based on project
management principles to achieve the stringent results required in
an effective way.
 The changing environments of software development such as
component-based, distributed and outsourced software
development require matching changes by project managers to
monitor, control and coordinate their projects.
•10
The Field
 Jobs: where are they?
Job Fundamentals
 Professional Organizations
 Skills required
 Project Management Institute
(PMI) (pmi.org)  PM Positions and
 Software Engineering Institute Roles
(SEI)  The Process
 IEEE Software Engineering Group
 Certifications
 PMI PMP
 Tools
 MS Project – many others
•1
1
what is a project
A Project is “a temporary attempt undertaken to create a unique
product, service, or result``.
Project Attributes
 A project has a unique purpose
 A Project is temporary
 A Project is developed using progressive elaboration
 A Project requires resources
 A Project should have a primary customer or sponsor
 A project involves uncertainty

•1-12
PROJECT ATTRIBUTES
a) A project has a unique purpose
Every project should have a well-defined objectives since a

project exist to achieve some specific outcomes. For example:
To improve a business process, create a specific product or
achieve a specific skill.
The purpose of a project is defined by the project requirements.
b) A Project is temporary
A project should have limited time spans: That is, a project has
a start date and a deadline date (End date) for completion.
•1-13
PROJECT ATTRIBUTES
c) A Project is developed using pregressive elaboration
Projects are often defined broadly when they begin, and as time
passes. The specific details of the project become clearer. A
project team should develop initial plans and then update them
with more detail based on new information.
d) A Project requires resources,
Resources include people, machinery, budget and other assets.

Resources however, are limited and must be used effectively to
meet project and other corporate goals.
•1-14
PROJECT ATTRIBUTES
e) A Project should have a primary customer or sponsor.
A sponsor usually provides the direction and funding for the

project.
f) A Project involves uncertainty
Because every project is unique, it is sometimes difficult to

define its objectives clearly, estimate how long it will take to
complete, or determine how much it will cost. External factors
also cause project uncertainty.
The uncertainty is one of the main reason Project Management is

•1-15
so challenging especially on projects involving new technologies.
The Triple Constraints Of Project
Management
Every project is constrained in different ways by its:

 Scope goals: What work will be done as part of the project?
 Time goals: How long should it take to complete?
 Cost goals: What should it cost to complete the project ?
 These limitations are sometimes referred to as the Triple
Constraints.
 It is the Project Manager’s duty to balance these three often-
competing goals in order to create a successful project.
 The relationship among these factor is such that if any one of the three
•1-16 factor changes, at least one other factor is likely to be affected.
The Triple Constraint of Project Management
•1-17
The Triple Constraints OF Project Management
.Managing the triple constraints involves making trade-
offs between scope, time, and cost goals for a project.
 For example, you might need to increase the Budget for a project to meet
Scope andTime goals.
 You might have to reduce the Scope of a project to meet Time and Cost
(Budget) goal.
 Experienced project managers know that you must
decide which aspect of the triple constraint is most
important.
 If Time is most important : Most often the initial project scope and/or
Cost goals need to be changed to meet the project schedule..
 If Scope goals are most important, then the time and /or Cost goals need
to be adjusted
•1-18
The Triple Constraints Of Project Management
 The Triple Constraint describes how the basic elements of a
project i.e. Scope,Time and cost interrelate.
 There are other elements such a : Quality, Customer

satisfaction and Sponsor satisfaction that can also play
significant roles.
 The Quadruple Constrains of Project Management which

includes `Quality` as well as Scope,Time, and Cost is also gaining
acceptance in the project management.
•1-19
 There is a common belief that the Quality considerations , including

Customer and/or Sponsor satisfaction , must be inherent in setting the
Project Scope, Time, and Cost goals of a project.
• A project team may meet Scope, Time and Cost Goals but fail to meet
quality standards or satisfy their sponsor, if they have not adequately
addressed these constraints.
e.g. A Project team may have completed the work on time

and within the cost constraint, but the quality may have been
unacceptable.
 A Project manager should be communicating with the project

sponsor throughout the project to make sure that the project meets
•1-20
the sponsor `s expectation.
How can you avoid the problems that occur when

meeting?
Project Scope, Time, and Cost goals, but lose sight of
quality or customer satisfaction?
 The answer is through a `Good Project Management`,

which includes more than meeting the triple
constraint,
•1-21
Benefits of Sound Project Management
 Less overall project cost
 Less strain on working capital
 Effective use of resources
 Timely project completion
 Higher quality of the final product
Project Management
 Complex and numerous activities
 Unique - a one time set of events
 Finite - a begin and end date
 Limited resources and budget
 Many people involved
 Sequenced activities
 End product or service must result
Program Management
 Larger in scope than a project
 Made up of several projects
 Made up of a number of similar products
 Programs tend to be more permanent
Project Management Skills
 Leadership
 Communications
 Problem Solving
 Negotiating
 Influencing the Organization
 Mentoring
 Process and technical expertise

5
Advantages of Using Formal
Project Management
 Better control of financial, physical, and human resources.
 Improved customer relations.
 Shorter development times.
 Lower costs.
 Higher quality and increased reliability.
 Higher profit margins.
 Improved productivity.
 Better internal coordination.
 Higher worker morale (less stress).
•26
Interactions / Stakeholders
 As a PM, who do you interact with?
 Project Stakeholders
 Project sponsor
 Executives
 Team
 Customers
 Contractors
 Functional managers

7
8
9
15 PM Job Functions
 Define scope of project  Evaluate project requirements
 Identify and evaluate risks Prepare
 Identify stakeholders, decision-
contingency plan
makers, and escalation
procedures  Identify interdependencies
 Identify and track critical
 Develop detailed task list (work
milestones
breakdown structures)
 Participate in project phase review
 Estimate time requirements
 Secure needed resources
 Develop initial project  Manage the change control process
management flow chart
 Report project status
 Identify required resources and
budget
*Northwest Center for Emerging Technologies, "Building a Foundation for Tomorrow: Skills Standards for
•Q7503 Principles of Project Management, Fall
Information Technology,"Belleview, WA, 1999
•30 2002
Hard and Soft Skills
for Project Managers
 Project managers also need “Hard” and “Soft” skills to achieve high
performance on projects..
Soft skills
Otherwise called Human Relations Skills include:
 Effective Communication
 Leadership
 Motivation
 Negotiation
 Problem solving
 Coping Skills (to manage)
•1-31
Soft skills (Continued)
Why do Project managers need Soft Skills?
 Project managers need soft skills to understand , navigate, and meet
stakeholders needs and expectation, project managers need to lead,
communicate, negotiate, solve problems and influence the organization at
large.
 Managers need to be able to listen actively to what others are saying. Help
develop new approaches for solving problems, and persuade others to work
toward achieving project goals.
 PM must lead project teams by providing vision, delegating work, creating
an energetic and positive environment, and setting an example of effective
behavior.
•1-32
Why do Project managers need Soft Skills? (Continued)
 PM focus on Teamwork skills to employ people effectively
 PM need to motivate different types of people
 PM also needs strong Coping skills to maintain their sanity and

reduce stress levels to cope with criticism and constant change,
since project work involve changes between competing goals
 PM must be flexible, creative, and sometimes patient in working

•1-33 toward project goals.
Hard Skills
 PM needs hard skills such as Product knowledge and knowing how to

use various Project Management tools and techniques.
 Due to the nature of the work; PMs make many decisions and deal
with people in a wide variety of disciplines, so it helps tremendously
to have a project manager who is confident in using the special tools
and techniques that are the most effective in particular settings.
 PMs do not normally have to be experts on any specific technology,

but they have to know enough to build a strong team and ask the right
•1-34 questions to keep things on track.
 For example;
PM for large IT projects do not have to be experts in the field of IT, but they
must have working knowledge of various technologies and understand how
the project would enhance the business.
Knowledge Programming languages
•1-35
Ten Most Important Skills For Project Managers
 Project management experts from various industries were asked to
identify the ten most important skills for effective Project Managers in a
recent study.
1. Domain Expertise
2. Leadership
3. Listening
4. Integrity, ethical behavior, consistent
5. Strong at building trust
6. Strong at building teams
7. Verbal communication
8. Conflict resolution, conflict management
9. Problem solving
•1-36 10. Understands
Most Important Skills and Competencies
 All PMs especially those working on technical projects, need
to demonstrate Leadership and Management skills.
 Leadership and Management are terms often used

interchangeable, although there are differences.
 A Leader focus on long-term goals and big-picture objectives,

while inspiring people to reach those goals.
 A Manager often deals with the day-to-day details of

meeting specific goals.
•1-37
Advantages of Using Formal
Project Management Practices
Improvement in customer satisfaction

Better cost performance, higher Return On Investment (ROI)
Better schedule performance, allocation of time commitments,
and utilization of resources, higher productivity
Increased quality and thus reducing re-work
Increase in delivering required features
Will make everyone happier (stakeholders, team members,
management …)
•1-38
Why Rapid Development
 Faster delivery
 Reduced risk
 Increased visibility to customer
 Don’t forsake quality

9
General Strategy For Rapid Dev
 Classic Mistake Avoidance
 Apply Development Fundamentals
 Risk Management
 Schedule-Oriented Practices
• McConnell refers to “Pillars”

• These provide balance
0
1
Schedule-oriented practices
 Three kinds of schedule-oriented practices:
• Practices that improve development speed, allowing
you to deliver software faster
• Practices that reduce schedule risk, allowing you to
avoid huge schedule overruns
• Practices that make progress visible, allowing you to
dispel the appearance of slow development

2
PMBOK
 Structures PM by
 A) Processes
 B) Knowledge Areas
 Processes. 2 types
 1. PM processes: describing and organizing the work
of the project
 2. Product-oriented processes: specifying and building
the project’s product
PMI Framework
•10th Knowledge Area Stakeholders Management

The 5 PMI Process Groups
 1. Initiating
 2. Planning
 3. Executing
 4. Controlling
 5. Closing
 Note: these can be repeated for each phase
 Each process is described by:
 Inputs
 Tools & Techniques
 Outputs
PMI Knowledge Areas

•46 2002
PMI: Initiating Process
 Inputs  Outputs
 Product Description  Project charter
 Strategic plan  Project Manager assigned
 Project Selection Criteria  Constraints
 Historical Information  Assumptions
•47 •Q7503 Principles of Project Management,

PMI: Planning Process
Devising and maintaining a workable scheme to accomplish the
business need that the project was undertaken to address
 Scope Planning  Risk Planning
 Scope Definition  Schedule Development
 Activity Definition  Quality Planning
 Activity Sequencing  Communications Planning
 Organization Planning
 Activity Duration Estimating
 Staff Acquisition
 Resource Planning
 Procurement Planning
 Cost Estimating  Project Plan Development
 Cost Budgeting

PMI: Executing Process
Coordinating people and other resources to carry out the plan
 Project Plan Execution  Information Distribution

 Scope Verification  Solicitation
 Quality Assurance  Source Selection
 Team Development  Contract Administration

PMI: Controlling Process
Ensuring that project objectives are met by monitoring and measuring
progress and taking corrective measures when necessary
 Overall Change Control  Performance Reporting
 Scope Change Control  Risk Response Control
 Schedule Control
 Cost Control
 Quality Control

•50 2002
PMI: Closing Process
Formalizing acceptance of the project or phase
and bringing it to an orderly end
 Administrative Closure
 Contract Close-out

PMI Process Groups
Source: Project Management Institute

Four Project Dimensions

3
Four Project Dimensions
 People
 Process
 Product
 Technology

4
People
 Improvements:
- Team selection: -Top talent, Job matching, Career progression,Team
balance, Misfit elimination
 Team organization. tailor teams to match project size, product
attributes, and schedule goals.
 Motivation. A person who lacks motivation is unlikely to work hard
Teams: 5-to-1 range

•5
.
•CSE-868 Software Project Management
5
People
 Staff selection for team projects: Barry Boehm presents five
principles of software staffing (Boehm 1981):-
 Top talent—Use better and fewer people.
 Job matching—Fit the tasks to the skills and motivation of the people
 available.
 Career progression—Help people to self-actualize rather than forcing
 them to work where they have the most experience or where they are
 most needed.
 Team balance—Select people who will complement and harmonize
 with each other.
 Misfit elimination—Eliminate and replace problem team members as
 quickly as possible.

6
Process
 Is process stifling?
 some processes are overly rigid or overly bureaucratic.
 Process abuse: People create process standards primarily to
make themselves feel powerful.
 Effect: developers find themselves working inefficiently
 2 Types: Management & Technical
 Development fundamentals
 Half of the challenge is avoiding disaster, at least in an area in
which standard software-engineering principles excel.

7
Process
 Quality assurance: - has two main purposes.
 The first, to assure that the product you release has an
acceptable level of quality.
 The second is to detect errors at the stage when they are least
time-consuming (and least costly) to correct.
 Risk management
 Managing schedule-related risks is a necessary component of a
rapid development program

8
Process
 Lifecycle planning
 A lifecycle model is useful because it describes a basic
management plan.
 For example, if you have a risky project, a risk-oriented
lifecycle model will suit you;
 and if you have vague requirements, an incremental lifecycle
model may work best.
 Lifecycle models make it easy to identify and organize many
activities required by a software project.

9
Process
 Customer orientation
 Strong focus on customers' needs and desires.
 The best practices such as;

 staged releases, evolutionary delivery, evolutionary prototyping,
throwaway prototyping, and principled negotiation can all give you
leverage in this area.

0
Process
 Process maturity improvement
 Rework avoidance
 One of the most straightforward ways to save time on a
software project is to orient your process so that you avoid
doing things twice.

1
Product
 The “tangible” dimension
 Product size management.
 If you can reduce a product's feature set, you can reduce the
product's schedule.
 If the feature set is flexible, you might be able to use the 80/20
rule and develop the 80 percent of the product that takes only
20 percent of the time.
 You can develop the other 20 percent later.

2
Product
 Product characteristics and requirements
 A product with ambitious goals for performance, memory use,
robustness, and reliability will take longer to develop than a
product without any goals for those characteristics.
 Feature creep management
 Customers gets educated once sees the product and then
demands more / enhanced features.

3
Technology
 Often the least important dimension
 Language and tool selection
 Changing from less effective tools to more effective tools can
also be a fast way to improve your development speed.
 Value and cost of reuse
 The current move toward component ware (VBXs and OCXs)
might eventually produce dramatic results

4
Management Fundamentals

5
Planning
 Determine requirements
 Determine resources
 Select lifecycle model
 Determine product features strategy

6
Tracking
 Cost, effort, schedule
 Planned vs. Actual
 How to handle when things go off plan?

7
Measurements
 To date and projected
 Cost
 Schedule
 Effort
 Product features
 Alternatives
 Earned value analysis
 Defect rates
 Productivity
 Complexity (ex: function points)

8
Technical Fundamentals

9
Technical Fundamentals
 Requirements
 Analysis
 Design
 Construction
 Quality Assurance
 Deployment

0
Project Phases
 All projects are divided into phases
 All phases together are known as the Project Life Cycle
 Each phase is marked by completion of Deliverables
 Identify the primary software project phases

1
Seven Core Project Phases

3
Phases Variation
Concept
Exploration
System
Exploration
Requirements
Design
Implementation
Installation
Operations and
Support
Maintenance
•7 •CSE-868 Software Project Management Retirement

4
36 Classic Mistakes

5
36 Classic Mistakes
 McConnell’s Anti-Patterns
 Types
 People-Related
 Process-Related
 Product-Related
 Technology-Related

6
Summary of Classic Mistakes
People-Related Mistakes Process-Related Mistakes Product-Related Mistakes Technology-Related Mistakes
1. Undermined motivation 14. Overly optimistic schedules 28. Requirements gold-plating 33. Silver-bullet syndrome
2. Weak personnel 16. Insufficient risk management 29. Feature creep 34. Overestimated savings from new
tools or methods
3. Uncontrolled problem employees 17. Contractor failure Insufficient 30. Developer gold-plating
planning 35. Switching tools in the middle of a
4. Heroics 31. Push me, pull me negotiation project
18. Abandonment of planning under
5. Adding people to a late project pressure 32. Research-oriented development 36. Lack of automated source-code
control
6. Noisy, crowded offices 19. Wasted time during the fuzzy
front end
7. Friction between developers and
customers 20. Shortchanged upstream activities
8. Unrealistic expectations 21. Inadequate design
9. Lack of effective project 22. Shortchanged quality assurance

sponsorship
23. Insufficient management controls
10. Lack of stakeholder buy-in
24. Premature or too frequent
11. Lack of user input convergence
12. Politics placed over substance 25. Omitting necessary tasks from
estimates
13. Wishful thinking
26. Planning to catch up later
27. Code-like-hell programming
•7
7
Questions

8
People-Related Mistakes Part 1
 Undermined motivation
 Study after study has shown that motivation probably has a
larger effect on productivity and quality than any other factor
(Boehm 1981).
 Weak personnel
 After motivation, either the individual capabilities of the team
members or their relationship as a team probably has the
greatest influence on productivity (Boehm 1981, Lakhanpal
1993)
 Weak vs. Junior – (Junior may not be weak)

9
 Uncontrolled problem employees
 Failure to deal with problem personnel also threatens
development speed.
 This is a common problem and has been well-understood at
least since Gerald Weinberg published Psychology of Computer
Programming in 1971.

0
 Heroics
 Some software developers place a high emphasis on project
heroics, thinking that certain kinds of heroics can be beneficial
(Bach 1995).
 Some managers encourage heroic behavior when they focus too
strongly on can-do attitudes.
 As Tom DeMarco says, can-do attitudes escalate minor setbacks
into true disasters (DeMarco 1995).

1
 Adding people to a late project
 This is perhaps the most classic of the classic mistakes.
 When a project is behind, adding people can take more
productivity away from existing team members than it adds
through new ones.
 Fred Brooks says adding people to a late project is like pouring
gasoline on a fire (Brooks 1975).

2
 Noisy, crowded offices
 Most developers rate their working conditions as unsatisfactory.
 About 60 percent report that they are neither sufficiently quiet
nor sufficiently private (DeMarco and Lister 1987).
 Customer-Developer friction
 Friction between developers and customers can arise in several
ways.
 Unrealistic expectations
 One of the most common causes of friction between developers
and their customers or managers is unrealistic expectations.

3
 Politics over substance
 Larry Constantine reported on four teams that had four
different kinds of political orientations (Constantine 1995a).
 "Politicians" specialized in "managing up” concentrating on relationships
with their managers.
 "Researchers" concentrated on scouting out and gathering information.
 "Isolationists" kept to themselves,
 "Generalists" did a little bit of everything

4
 Politics over substance
 Constantine reported that initially the political and generalist
teams were both well regarded by top management.
 But after a year and a half, the political team was ranked dead
last.
 Conclusion: Putting politics, over results is fatal to speed-
oriented development.

5
 Wishful thinking
 Wishful thinking isn't just optimism. It's closing your eyes and
hoping something works when you have no reasonable basis for
thinking it will.
 Wishful thinking at the beginning of a project leads to big
blowups at the end of a project.
 It undermines meaningful planning and may be at the root of
more software problems than all other causes combined.

6
 Lack of effective project sponsorship
 Without an effective executive sponsor, other high-level
personnel in your organization can force you to accept
unrealistic deadlines or make changes that undermine your
project.
 Australian consultant Rob Thomsett argues that lack of an
effective executive sponsor virtually guarantees project failure
(Thomsett 1995).

7
 Lack of stakeholder buy-in
 All the major players in a software-development effort must
buy in to the project.
 That includes the executive sponsor, team leader, team
members, marketing staff, end-users, customers, and anyone
else who has a stake in it
 Lack of user input
 Projects without early end-user involvement risk
misunderstanding the projects' requirements and are vulnerable
to time-consuming feature creep later in the project.

8
Process-Related Mistakes Part 1
 Optimistic schedules
◦ Setting an overly optimistic schedule sets a project up for failure by
under scoping the project, undermining effective planning, etc
 Insufficient risk management
◦ Some mistakes are not common enough to be considered classic.
◦ Those are called "risks.“
◦ The failure to manage such unique risks is a classic mistake
 Contractor failure
◦ But contractors frequently deliver work that's late, that's of
unacceptably low quality, or that fails to meet specifications (Boehm
1989).

9
 Insufficient planning
 If you don't plan to achieve rapid development, you can't expect
to achieve it
 Abandonment of plan under pressure
 Project teams make plans and then routinely abandon them
when they run into schedule trouble (Humphrey 1989).
 The problem isn't so much in abandoning the plan as in failing
to create a substitute, and then falling into code-and-fix mode
instead.

0
 Wasted time during fuzzy front end
◦ The "fuzzy front end" is the time before the project starts, the time
normally spent in the approval and budgeting process.
◦ It's not uncommon for a project to spend months or years in the
fuzzy front end and then to come out of the gates with an aggressive
schedule.
 Shortchanged upstream activities
◦ Projects that are in a hurry try to cut out nonessential activities.
◦ Since requirements analysis, architecture, and design don't directly
produce code, they are easy targets.
◦ The results of this mistake—also known as "jumping into coding"—
are all too predictable.

1
 Inadequate design
 A special case of shortchanging upstream activities is inadequate
design.
 Rush projects undermine design by not allocating enough time
for this thoughtful activity.
 Shortchanged quality assurance
 Projects that are in a hurry often cut corners by eliminating
design and code reviews, eliminating test planning, and
performing only perfunctory testing.

2
 Insufficient management controls
 Before you can keep a project on track, you have to be able to
tell whether it's on track in the first place.
 Frequent convergence
 On rush projects, there is a tendency to force convergence
early. – done many times
 The extra convergence attempts don't benefit the product. They
just waste time and prolong the schedule.

3
 Omitting necessary tasks from estimates
◦ If people don't keep careful records of previous projects, they forget about the
less visible tasks, but those tasks add up.
◦ Omitted effort often adds about 20 to 30 percent to a development schedule (van
Genuchten 1991).
 Planning to catch-up later
◦ Many projects simply plan to catch up later, but they never do.
◦ You learn more about the product as you build it, including more about what it
will take to build it.
◦ That learning needs to be reflected in the re-estimated schedule.

4
 Code-like-hell programming
 Some organizations think that fast, loose, all-as-you-go coding is
a route to rapid development.
 It is really just a cover for the old Code-and-Fix paradigm
combined with an ambitious schedule, and that combination
almost never works.

5
Product-Related Mistakes
 Requirements gold-plating
 Some projects have more requirements than they need, right
from the beginning
 Users tend to be less interested in complex features than
marketing and development are, and complex features add
disproportionately to a development schedule.
 Feature creep
 Even if you're successful at avoiding requirements gold plating,
the average project experiences about a 25-percent change in
requirements over its lifetime (Jones 1994).

6
 Developer gold-plating
 Developers are fascinated by new technology and are
sometimes anxious to try out new features of their language or
environment or to create their own implementation of a slick
feature they saw in another product—whether or not it's
required in their product.
 The effort required to design, implement, test, document, and
support features that are not required lengthens the schedule.

7
 Push-me, pull-me negotiation
 One common mistake occurs when a manager approves a
schedule slip on a project that's progressing slower than
expected and then adds completely new tasks after the schedule
change.
 This can't help but undermine the schedule

8
 Research-oriented development
 If your project strains the limits of computer science by
requiring die creation of new algorithms or new computing
practices, you're not doing software development; you're doing
software research.
 Software-development schedules are reasonably predictable;
software research schedules are not even theoretically
predictable.

9
Technology-Related Mistakes
 Silver-bullet syndrome
◦ a quick solution to a difficult problem – often does not work
 Overestimated savings from new tools and methods
◦ Benefits of new practices are partially offset by the learning curves
associated with them, and learning to use new practices to their
maximum advantage takes time.
◦ New practices also entail new risks, which you're likely to discover
only by using them.
◦ You are more likely to experience slow, steady improvement on the
order of a few percent per project than you are to experience
dramatic gains.
•1
0 •CSE-868 Software Project Management
0
 Switching tools in mid-project
 This is an old standby that hardly ever works.
 But the learning curve, rework, and inevitable mistakes made
with a totally new tool usually cancel out any benefit when
you're in the middle of a project.
•1
1
 Lack of automated source-code control
 Failure to use automated source-code control exposes projects
to needless risks.
 Without it, if two developers are working on the same part of
the program, they have to coordinate their work manually.
 On average, source code changes at a rate of about 10 percent
per month, and manual source-code control can't keep up
(Jones 1994)
•1
2
Reading
 McConnell: Chapters 1-3
 We covered most of Ch 3 today
 Case studies
 2-1, 2-2, 3-1
•1
3

CS-868 Software Project Management

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CS-868 Software Project Management

Uploaded by

Copyright:

Available Formats

CS-868 Software Project Management

CS-868 Software Project Management

 Class Session Wed 5:30---8:30 pm

 Office Hours After class, via email, or by appointment

•3 •CSE-868 Software Project Management

•5 •CSE-868 Software Project Management

2.Software Project Management - Bob Hughes -2nd Ed-1999

3.“Software Project Survival Guide”, Steve McConnell

•7 •CSE-868 Software Project Management

•8 •CSE-868 Software Project Management

 To understand the processes, tools,

 A Project is developed using progressive elaboration

 A Project requires resources

 A Project should have a primary customer or sponsor

 A project involves uncertainty

Every project should have a well-defined objectives since a

The purpose of a project is defined by the project requirements.

d) A Project requires resources,

Resources include people, machinery, budget and other assets.

A sponsor usually provides the direction and funding for the

f) A Project involves uncertainty

Because every project is unique, it is sometimes difficult to

The uncertainty is one of the main reason Project Management is

Every project is constrained in different ways by its:

 There are other elements such a : Quality, Customer

 The Quadruple Constrains of Project Management which

 There is a common belief that the Quality considerations , including

e.g. A Project team may have completed the work on time

 A Project manager should be communicating with the project

How can you avoid the problems that occur when

 The answer is through a `Good Project Management`,

•2 •CSE-868 Software Project Management

•2 •CSE-868 Software Project Management

 PM focus on Teamwork skills to employ people effectively

 PM need to motivate different types of people

 PM also needs strong Coping skills to maintain their sanity and

 PM must be flexible, creative, and sometimes patient in working

 PM needs hard skills such as Product knowledge and knowing how to

 PMs do not normally have to be experts on any specific technology,

Knowledge Programming languages

 Leadership and Management are terms often used

 A Leader focus on long-term goals and big-picture objectives,

 A Manager often deals with the day-to-day details of

Improvement in customer satisfaction

•3 •CSE-868 Software Project Management

• McConnell refers to “Pillars”

•4 •CSE-868 Software Project Management

•10th Knowledge Area Stakeholders Management

•Q7503 Principles of Project Management, Fall

•47 •Q7503 Principles of Project Management,

•48 •Q7503 Principles of Project Management,

 Project Plan Execution  Information Distribution

•49 •Q7503 Principles of Project Management,

•Q7503 Principles of Project Management, Fall

•51 •Q7503 Principles of Project Management,

Source: Project Management Institute

•5 •CSE-868 Software Project Management

•5 •CSE-868 Software Project Management

Teams: 5-to-1 range

•5 •CSE-868 Software Project Management

•5 •CSE-868 Software Project Management

•5 •CSE-868 Software Project Management

•5 •CSE-868 Software Project Management