Project Management and Planning

Based on Chp 22 & 23 of Sommerville “Software Engineering” (9th edition)

CMPT 276, Spring 2019, SFU Surrey

Teams

in real life, working well with other people on teams is extremely common

working on a project all by yourself is relatively rare

you don’t always get to chose your teammates

you need learn to work with “difficult” people

keep in mind that sometimes, in the eyes of other, you may be the difficult person!

practice and experience helps

Teams

“People” issues can be significant, e.g.

• different knowledge
• different preferences
• different attitude towards attending meetings on time (if at all)
• different work habits
• feelings that a teammate has done more/less work than others
• someone leaves the team

in general, you want to act professionally and try hard to respond constructively to inter-personal challenges

Teams

how big should a team be?

• how long should a piece of string be?

larger projects of course need bigger teams

but managing bigger teams presents significant challenges

• harder to make schedules
• harder to modularize and track work being done
• more communication channels

larger teams need a project manager to keep them well organized

• smaller teams can also benefit from project-management techniques

Managing People

managing people is hard, and generally requires significant expertise and experience

your project team should probably make someone the project manager

• team members could take turns being the project manager, or manage certain parts of your teams work

some advice for dealing with people as a manager

• be consistent: treat everyone fairly, and try not to play favourites
• be respectful: different people have different skills
• be inclusive: listen to everyone’s opinion and try to make everyone feel valued
• be honest: be honest about what’s going well, and not going well

Teams: The Bus Factor

one thing to consider with a team is its so-called bus factor

bus factor = the minimum number of team members that need to “disappear” (e.g. get run over by a bus) for the project to fail

a bus number of 1 means there is someone on your team who, if they leave, will cause your project to fail

this is bad!

you never know who might leave, or for what reason

try to organize your groups work so that its bus factor is as high as possible, e.g.

• document your project well enough for new people to understand
• have more than one person work on each essential part of the project

Brooks Law

Brook’s Law: adding people to a late software project makes it later

this may seem counter-intuitive, but:

• it takes time for new people to “ramp up” and learn enough about the project to be useful
• every new person adds more channels of communication

Fred Brooks famously lead the team that developed the software for the influential IBM 360 mainframe computer in the 1960s

he documented his experience in the excellent book “The Mythical Man-Month”

• you should read it: filled with wisdom!

Risks

when planning a project, it’s a good idea to think ahead of time about things that might go wrong, or could cause problems

trying to predict risks is usually a very good thing to do when planning a project

how can risks be avoided?

if they can’t be avoided, how could their impact be minimized?

at least three general categories of risk to consider

• project risks
• product risks
• business risks

Risks: Project, Product, Business

project risks affect the project schedule or resources, e.g.

• a team member leaves
• the product has to be finished earlier than planned

product risks affect the quality or performance of the software being developed

• your are creating an iPhone app, and a major operating-system update occurs in the middle of your project
• the database you planned to use turns out to be too inefficient

business risks affect the organization developing or purchasing the software

• the purchaser changes what they want half-way through
• a competitor releases a similar product

keep in mind these are not mathematically precise categories: risks could overlap more then one category

Risks: Common Kinds

technology risks, e.g. a code library is too slow, or lacks essential features

people risks, e.g. someone is sick during a critical part of the project

requirement risks, e.g. you promised to deliver a big, complicated feature that no one on your team has experience with

estimation risks, e.g. you estimated that implementing a certain feature would take 2 days, but instead it took 10 days

Risk Management

risk identification

• brainstorm to come up with a list of the most important project, product, and business risks

risk analysis

• think about how likely the risks are, and how big their impact might be
• useful formula: Risk of R = (probability of R occurring) * (loss due to R)

risk planning

• come up with a plan for dealing with the most important risks

risk monitoring

• re-assess risks and plans throughout project
• as the project continues, some risks might vanish, new ones might appear

Risk Management

risk identification, e.g. team members will be busy at end of semester due to exams and assignments in other courses

risk analysis, e.g. how many courses are team members taking? what sort of work do they expect to have due at the end of the semester?

risk planning, e.g. carefully schedule the last couple of weeks of the project, and have team members to schedule their other end-of-semester work

risk monitoring, e.g. a couple of times during the semester, re-check how busy team members will be at end of semester; does anyone have new things due? or have they dropped a course?

Project Planning

the bigger and more complicated a project is, the more it pays to plan things out ahead of time

project planning typically consists of

• discussions among “stakeholders” about the what the project is about, how it will get paid for, how big it is, etc
• creating a project plan document that stakeholders agree to

stakeholders include everyone associated with the project, both technical people (i.e. programmers) and non-technical people (e.g. salespeople, accountants, end-users, etc.)

Project Plan Document

introduction

• what is the project about?

project organization

• the basic structure of the team, e.g. roles that people will take on, how they will communicate, etc.

risk analysis

• key risks, and how they will be dealt with

hardware and software requirements

• hardware and software that is needed, both for development and after development during production

work breakdown

• a detailed list of all the expected work and deliverables

project schedule

• a detailed list of all the important due dates and milestones

monitoring and reporting mechanisms

• how will the team report on what its doing?
• how will re-planning work?

Project Plan Document: A Hypothetical Example

introduction

• SFU student digital portfolio software that lets students archive and display their digital work

project organization

• 1 project manager, 3 general programmers, 2 media database specialists; 2 server/networking specialists; 2 visual designers; following an iterative process

risk analysis

• multimedia database performance and space; usability for students; privacy and legal issues, etc.

hardware and software requirements

• large amount of storage will be needed for prototyping and deployment; database software is proprietary; private collaboration software; some non-free software tools (static analysis tools, performance-analysis, test case management)

work breakdown

• software requirements gathering, design, implementation, testing; creation of UI elements and look-and-feel; significant system-testing before deployment (plus much more detail about important work!)

project schedule

• prototype demo after 10 months; system deployed in 24 months (plus much more detail about all important dates!)

monitoring and reporting mechanisms

• monthly stakeholders meeting to report on progress; project manager will review project status every 2 weeks (etc.)

Project Planning

a major difficulty with project planning is that it must be done at the start of the project, which is when you have the least information and experience with the project

it can seem like almost everything is impossible to predict with any accuracy!

you might not even be sure yet of everything that must be done

how do you predict how long it will take to finish a feature?

because of these uncertainties, re-planning is important

as you learn more about the project, you should adjust your plans

so-called “agile” software development takes this to heart

Agile Planning: Extreme Programming

Extreme Programming was one of the first “agile” programming methodologies

it uses a collaborative planning technique called the planning game

collect user stories (i.e. usage scenarios, or use cases) about features

• every feature of the software should solve a specific problem that users have

the team ranks user stories in order of importance, and then estimates how much effort each story will take by assigning effort points (e.g. an 8-point story takes twice as much effort as 4-point story)

team velocity is then estimated by determining how many effort-points per working day the team can get done

user stories are then chosen to implement for each iteration of the project, and more details about them are fleshed-out before being implemented

all team members participate in the planning, and so ideally everyone gets the chance to work on features they choose

• as opposed to everyone being assigned a task by the project manager

Estimating Techniques

estimating time and work is difficult for most people

• even as a junior programmer, you may be asked to estimate how long it will take you to finish a task

one of the best ways to do this to have a lot of experience!

• work on lots of projects, keep track of how much time things take
• having a group of people discuss estimates together is often better than doing it alone

another way is to use some sort of formula to estimate time

• e.g. (informal estimate of time) * 3
• this is surprisingly common and useful rule of thumb
• the intuition is that people usually plan for the “best case”, and so doubling or tripling that is a way to deal with all the unknowns

e.g. COCOMO II model

• this is a empirically-based formulaic approach to software estimation (see chp 23 to get a taste of what its like)

Examples of Planning/Scheduling Software Tools

(Excel) spreadsheets

• you can find templates for many different project management tasks

Slack

• group communication tool that archives files, conversations, etc.

Jira

• a popular issue-tracker and agile project-management tool

Trello

• a popular planning/scheduling tool that uses boards, list, and cards for a variety of tasks
• free

your team should use some sort of software to help track its plan, schedule, and work assignments

the main thing is to keep track of all the important details, and update them when they change

Example: Kanban Board

one way to use a tool like Trello is to arrange it as a Kanban board

add columns like this:

• Up next: tasks that need to be worked on next (chosen from backlog, as discussed below)
• In progress: tasks that are currently being worked on
• Completed: tasks that have been finished
• Backlog: all other tasks; add any tasks that you can think of here

move tasks between the columns as they get worked on

any time you look at the board you should be able to see that state of your project

can be a practical balance between informal planning/scheduling, and highly-detailed bar charts

Planning: Things to Keep in Mind

the fundamental idea is

• divide your project into smaller tasks
• carefully estimate the size of these tasks, and track them

the bigger and more complicated a project, the more detailed the plan should be

• don’t over-plan
• plan to re-plan!

no one gets things exactly right at the start

as your project progresses and you learn more, update your plans