An overview of project management for small web projects. This was created especially to address PM needs for the <a>Williams WIT program</a>, which has about 8 weeks of development time and new/junior developers.

1. WIT Project Management a quick and dirty introduction to project management for small web development projects with new and junior developers

2. 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

3. 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

4. Waterfall PM – Software Development Initiation Specification Planning & Design Implementation Testing and Debugging Release & Hand-off Maintenance

5. 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

6. 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)

7. Iterfall (Iterative Waterfall) Initiation Specification Planning Design Implementation Testing and Debugging Release & Hand-off Maintenance

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. WITerfallPhases for WIT Initiation – done a clear vision is last step of 1 or the first step of 2 Specification (trad) – lots of help Planning (hybrid) – moderate help Design (agile) – minimal help Implementation (agile) – minimal help Testing and Debugging (agile) – minimal help Release & Hand-off (hybrid) – moderate help Maintenance – outside WIT

16. Specification Work with sponsors, or at least provide educated guesses 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

17. 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

18. 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

19. Project Milestones (Web) Project management set up Project Specified Documentation framework set up Development environment set up Content organized Base theme chosen (WP) Functioning web site Placeholder content entered Visual mockups approved Media prepared Custom functionality implemented Theme finished Media deployed Final content in place Help docs complete Sponsor approval Released Handed off to sponsor Presentation Done

20. 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)