Web Project Management for Small Projects


Published on

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.

Web Project Management for Small Projects

  1. 1. WIT Project Management<br />a quick and dirty introduction to project management for small web development projects with new and junior developers<br />
  2. 2. Why Formal Project Management<br />understand the project<br />increase likelihood of success<br />know what success is<br />reduce stress<br />make effective use of resources<br />fit the project into a larger context<br />other projects<br />external events<br />reduce uncertainty<br />
  3. 3. Traditional PM<br />4-5 main phases<br />initiation/vision<br />planning/design<br />execution/development<br />evaluation/monitoring & control<br />closing/deployment/release<br />lots of planning<br />clean hand off between phases<br />
  4. 4. Waterfall PM – Software Development<br />Initiation<br />Specification<br />Planning & Design<br />Implementation<br />Testing and Debugging<br />Release & Hand-off<br />Maintenance<br />
  5. 5. Limitations of Traditional PM<br />inflexible<br />new info<br />project changes<br />known-result oriented<br />overwhelming<br />both takes over and intimidating<br />benefits drop for smaller projects<br />high overhead<br />misses some key web/software aspects<br />
  6. 6. Software/Web PM<br />often exploratory / inventive<br />high uncertainty<br />particular focus on testing / debugging<br />additional post-release maintenance phase<br />requirements are often fluid<br />stakeholders often don’t understand the capabilities of the technology<br />direct stakeholder interaction (WIT)<br />
  7. 7. Iterfall (Iterative Waterfall)<br />Initiation<br />Specification<br />Planning <br />Design<br />Implementation<br />Testing and Debugging<br />Release & Hand-off<br />Maintenance<br />
  8. 8. Agile PM / XP / etc<br />created explicitly for quick software development<br />functionality focused<br />very flexible<br />very human-interactive<br />works well for small, tight teams<br />most appropriate for non-critical projects<br />
  9. 9. Agile Details<br />break tasks into small increments<br />project is a series of iterative cycles<br />very short, 1-4 weeks<br />spec, plan, dev, testing process for that short span<br />results in a working product<br />team (5-9 people) is cross functional and self organizing<br />plan is more general further off in time<br />
  10. 10. Agile PM sounds good, BUT...<br />Agile PM / XP / etc. requires senior developers to be effective!<br />requires very frequent sponsor feedback<br />relies on people being able to self-organize<br />leverages expertise – low/no expertise greatly reduces benefits<br />echo chamber can enhance mistakes<br />
  11. 11. A Middle Ground<br />traditional (planning oriented)<br />clear project understanding<br />guidance for junior developers<br />easier top-down involvement<br />agile (implementation & feedback oriented)<br />well suited to web / software development<br />self-directed and -organized where possible<br />team oriented<br />flexible<br />working product oriented<br />
  12. 12. Existing Solutions<br />there are a number of processes out there that attempt to balance TPM and APM. Generally they<br />are for larger projects<br />are for longer time frames<br />trade on the certainty–flexibility axis<br />rely on (at least some) experienced developers<br />
  13. 13. Main Goals for WIT PM<br />fit the project into the fixed time frame (7-8 weeks)<br />make sure it’s feasible<br />make sure work is being done<br />flexibility<br />semi-fluid requirements / goals (BUT, minimal scope creep)<br />self-organizing where possible<br />guide junior developers<br />clearly defined responsibilities<br />tasks that need doing<br />limits of scope<br />intern responsibilities<br />sponsor responsbilities<br />sponsors...<br />work directly with interns (faculty-student interaction is a key part of WIT)<br />are happy with the results<br />students...<br />work directly with faculty (see above)<br />get training, up front and ongoing<br />self-evaluate, both process and product<br />
  14. 14. Combining Traditional and Agile<br />traditional provides larger structure<br />over all time frame<br />abstract milestones<br />easily teachable approach<br />clear goals<br />agile provides per-task implementation model<br />team oriented<br />exploratory<br />flexibility<br />
  15. 15. WITerfallPhases for WIT<br />Initiation – done<br />a clear vision is last step of 1 or the first step of 2<br />Specification (trad) – lots of help<br />Planning (hybrid) – moderate help<br />Design (agile) – minimal help<br />Implementation (agile) – minimal help<br />Testing and Debugging (agile) – minimal help<br />Release & Hand-off (hybrid) – moderate help<br />Maintenance – outside WIT<br />
  16. 16. Specification<br />Work with sponsors, or at least provide educated guesses<br />Project Overview<br />high-level why’s<br />high-level what’s<br />major, key points<br />specific what’s<br />specific technologies involved<br />Content Description<br />Maintainers<br />who (individual or ex officio)<br />what parts<br />when and how<br />Requirements<br />subjective goals / guides<br />objective, measurable goals / deliverables<br />Scope Limits<br />degree of uncertainty<br />likelihood of change<br />outer bounds<br />Stakeholders<br />Audience<br />or ordered list of audiences<br />
  17. 17. Planning the Work<br />Milestones<br />what & when : an ordered list of stages<br />Tasks (/Tickets/Items/Steps/ToDo’s/etc.)<br />associated with a milestone<br />note specialized skill requirements<br />likely problem areas<br />note dependencies<br />and opportunities for parallel work<br />
  18. 18. Milestone and Task (and Dependency Problem) Example<br />Lawn is mowed<br />get lawn mower back from neighbor<br />return special Tibetan pillow to neighbor<br />fix pillow<br />get stuffing<br />shave yak<br />break in to zoo<br />explain to the nice officer why you’re climbing the fence to the yak exhibit with a razor and a can of Barbisol<br />
  19. 19. Project Milestones (Web)<br />Project management set up<br />Project Specified<br />Documentation framework set up<br />Development environment set up<br />Content organized<br />Base theme chosen (WP)<br />Functioning web site<br />Placeholder content entered<br />Visual mockups approved<br />Media prepared<br />Custom functionality implemented<br />Theme finished<br />Media deployed<br />Final content in place<br />Help docs complete<br />Sponsor approval<br />Released<br />Handed off to sponsor<br />Presentation Done<br />
  20. 20. Milestone Breakdown<br />Project management set up<br />zoho account & sharing (& project lead)<br />PM training<br />Project Specified (see spec slide)<br />specs developed<br />specs entered in zoho<br />reviewed with sponsor and signed off<br />Development environment set up<br />accounts et al<br />shell accounts<br />samba accounts<br />WP dev area<br />webdev area<br />source control<br />text / code editing software<br />graphic design software<br />browser plugins<br />references (links, books, people)<br />
  21. 21. Workflow<br />designs<br />ITS sees and signs off<br />sponsor sees and signs off<br />project architecture<br />review plan<br />work proceeds<br />databases<br />review DB structures<br />data entry and/or coding<br />debugging<br />self<br />team mate<br />ITS<br />Chris or Kate<br /><ul><li>spec change from sponsor</li></ul>talk w/ ITS<br />ITS, sponsor, and team meeting<br />work proceeds<br /><ul><li>movies</li></ul>script written<br />script approved by Tamra and Phil<br />script approved by sponsor<br />story board done<br />story board approved by ITS<br />story board approved by sponsor<br />filming starts<br />