WIT Project Management

a quick and dirty introduction to project management for small web development projects with new and junior developers

Why Formal Project Management

• understand the project• increase likelihood of success– know what success is

• reduce stress• make effective use of resources• fit the project into a larger context– other projects– external events

• reduce uncertainty

Traditional PM

• 4-5 main phases– initiation/vision– planning/design– execution/development• evaluation/monitoring & control

– closing/deployment/release• lots of planning• clean hand off between phases

Waterfall PM – Software Development

1. Initiation2. Specification3. Planning & Design4. Implementation5. Testing and Debugging6. Release & Hand-off7. Maintenance

Limitations of Traditional PM

• inflexible– new info– project changes

• known-result oriented• overwhelming– both takes over and intimidating

• benefits drop for smaller projects– high overhead

• misses some key web/software aspects

Software/Web PM

• often exploratory / inventive– high uncertainty

• particular focus on testing / debugging• additional post-release maintenance phase• requirements are often fluid• stakeholders often don’t understand the

capabilities of the technology• direct stakeholder interaction (WIT)

Iterfall (Iterative Waterfall)

1. Initiation2. Specification3. Planning 4. Design5. Implementation6. Testing and Debugging7. Release & Hand-off8. Maintenance

Agile PM / XP / etc

• created explicitly for quick software development

• functionality focused• very flexible• very human-interactive• works well for small, tight teams• most appropriate for non-critical projects

Agile Details

• break tasks into small increments• project is a series of iterative cycles– very short, 1-4 weeks– spec, plan, dev, testing process for that short span– results in a working product

• team (5-9 people) is cross functional and self organizing

• plan is more general further off in time

Agile PM sounds good, BUT...

• Agile PM / XP / etc. requires senior developers to be effective!

• requires very frequent sponsor feedback• relies on people being able to self-organize• leverages expertise – low/no expertise greatly

reduces benefits– echo chamber can enhance mistakes

A Middle Ground

• traditional (planning oriented)– clear project understanding– guidance for junior developers– easier top-down involvement

• agile (implementation & feedback oriented)– well suited to web / software development– self-directed and -organized where possible– team oriented– flexible– working product oriented

Existing Solutions

• there are a number of processes out there that attempt to balance TPM and APM. Generally they– are for larger projects– are for longer time frames– trade on the certainty–flexibility axis– rely on (at least some) experienced developers

Main Goals for WIT PM• fit the project into the fixed time frame (7-8 weeks)

– make sure it’s feasible– make sure work is being done

• flexibility– semi-fluid requirements / goals (BUT, minimal scope creep)– self-organizing where possible

• guide junior developers• clearly defined responsibilities

– tasks that need doing– limits of scope– intern responsibilities– sponsor responsbilities

• sponsors...– work directly with interns (faculty-student interaction is a key part of WIT)– are happy with the results

• students...– work directly with faculty (see above)– get training, up front and ongoing– self-evaluate, both process and product

Combining Traditional and Agile

• traditional provides larger structure– over all time frame– abstract milestones– easily teachable approach– clear goals

• agile provides per-task implementation model– team oriented– exploratory– flexibility

WITerfall Phases for WIT

1. Initiation – done– a clear vision is last step of 1 or the first step of 2

2. Specification (trad) – lots of help3. Planning (hybrid) – moderate help4. Design (agile) – minimal help5. Implementation (agile) – minimal help6. Testing and Debugging (agile) – minimal help7. Release & Hand-off (hybrid) – moderate help8. Maintenance – outside WIT

Specification

• Project Overview– high-level why’s– high-level what’s– major, key points

• specific what’s• specific technologies involved

• Content Description• Maintainers

– who (individual or ex officio)– what parts– when and how

• Requirements– subjective goals / guides– objective, measurable goals /

deliverables

• Scope Limits– degree of uncertainty– likelihood of change– outer bounds

• Stakeholders• Audience

– or ordered list of audiences

Work with sponsors, or at least provide educated guesses

Planning the Work

• Milestones– what & when : an ordered list of stages

• Tasks (/Tickets/Items/Steps/ToDo’s/etc.)– associated with a milestone– note specialized skill requirements• likely problem areas

– note dependencies• and opportunities for parallel work

Milestone and Task (and Dependency Problem) Example

• Lawn is mowed– get lawn mower back from neighbor• return special Tibetan pillow to neighbor

– fix pillow» get stuffing

• shave yak• break in to zoo

• explain to the nice officer why you’re climbing the fence to the yak exhibit with a razor and a can of Barbisol

Project Milestones (Web)

1. Project management set up2. Project Specified3. Documentation framework

set up4. Development environment

set up5. Content organized6. Base theme chosen (WP)7. Functioning web site8. Placeholder content entered9. Visual mockups approved

10. Media prepared11. Custom functionality

implemented12. Theme finished13. Media deployed14. Final content in place15. Help docs complete16. Sponsor approval17. Released18. Handed off to sponsor19. Presentation Done

Milestone Breakdown• Project management set up

– zoho account & sharing (& project lead)– PM training

• Project Specified (see spec slide)– specs developed– specs entered in zoho– reviewed with sponsor and signed off

• Development environment set up– accounts et al

• shell accounts• samba accounts• WP dev area• webdev area• source control

– text / code editing software– graphic design software– browser plugins– references (links, books, people)

Workflow

• designs1. ITS sees and signs off2. sponsor sees and signs off

• project architecture1. review plan2. work proceeds

• databases1. review DB structures2. data entry and/or coding

• debugging1. self2. team mate3. ITS4. Chris or Kate

• spec change from sponsor1. talk w/ ITS2. ITS, sponsor, and team

meeting3. work proceeds

• movies1. script written2. script approved by Tamra and

Phil3. script approved by sponsor4. story board done5. story board approved by ITS6. story board approved by

sponsor7. filming starts