Realising Dreams: Building for the Web

1,379 views

Published on

This was a guest lecture I presented to Masters students of information science at McGill University. It was intended to give an idea of what it's like in reality, lessons learned - and why certain traditional notions of project management doesn't work well in industry (and that we're still struggling with it).

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,379
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Realising Dreams: Building for the Web

  1. 1. Realising dreams Building for the web Stephanie Troeth November 24 2008 School of Information Studies McGill University, Montreal.
  2. 2. Overview Who’s responsible? The role of the web project manager / product manager / web producer What needs to done? The reality of what is required for us to build a good product. How can we do it? Borrowing from the way of web 2.0. How can we plan for uncertainty? Some techniques for estimating.
  3. 3. Who’s responsible? The myths of the role of the project manager, the web producer, et al.
  4. 4. Observation #1 Role definition is hard to find. This should send us a warning signal.
  5. 5. What is a project manager? “Project managers sit between account managers and the project team and have a comprehensive understanding of the web development cycle. They are fanatical organisers, have a full overview of the project and are responsible for all key elements of it; leadership, risk management and working progress/tracking; always with an eye on commercial requirements/restraints [...]” Source: http://www.e-consultancy.com/forum/109564-web-producer-versus-web-project-manager.html
  6. 6. What is a producer? “Producers tend to sit within the creative studio. They have coding and design skills, so a hands- on understanding of creative and development, plus actually ‘produce’ site maps and wireframes. They also co-ordinate customer research and user testing.” Source: http://www.e-consultancy.com/forum/109564-web-producer-versus-web-project-manager.html
  7. 7. Comparing roles Project manager Producer • identify project objectives & success criteria • working technical knowledge • scope definition • works with designers, developers • documentation: project plans, • set accurate project timelines scoping, specs reporting tools • liaise with client for sign-off on • understand current best practices (usability, accessibility, IA) key project documents • track project status, provide • produce sitemaps & wireframes regular reports • manage small teams • identifying risks and solutions • coordinate budgets • project costing & budget • develop process and best practices between teams • implement project management methodology • coordinate quality control • quality control Adapted from: http://www.e-consultancy.com/forum/109564-web-producer-versus-web-project-manager.html
  8. 8. What is a producer? “The quot;Producerquot; is responsible for overall project design and creation, including the sum total of the creative efforts of the design staff. This person leads all phases of the design process from concept through development to ultimate completion. The Producer is subject to the supervision of the Project Manager.” Source: http://archives.hwg.org/hwg-basics/003101bf1fe7$86d3d800$18c315d0@derrienrelyea
  9. 9. Observation #2 Consensus of roles does not appear to exist. This should send us another warning signal.
  10. 10. The project manager may not often be a popular person. “Voldemort as Project Manager” by Kevin Dooley http://flickr.com/photos/pagedooley/2802321479/
  11. 11. Because we tend to treat projects like a manufacturing process, we expect people and tasks to be as identifiable & manageable as cogwheels — which cannot always be true.
  12. 12. The project manager or producer has the task of balancing dream and reality in the building of a web site.
  13. 13. What needs to be done? The reality of what is required for us to build a good product.
  14. 14. A dream Imagine the following case study. A travel agency wants to update their online presence to include: • a fresh new look • an update of their travel packages • features for obtaining quotes online
  15. 15. A dream ...? More likely they will ask for: • “just a re-skin” • “something like an online shop” And we would have to decipher and establish what the requirements actually are.
  16. 16. The reality ... • Branding • Content production • Marketing & promotion • Interface Development • Analysis • Application development • Production planning • Quality assurance & testing • Art Direction & • Deployment Graphic Design • User experience design • Maintenance/enhancements
  17. 17. Interdependence of project activities Art Direction Graphic design Branding UserX design Interface dev. Application dev. Analysis Content production QA & Testing Deployment
  18. 18. So, who are the people doing these activities? What skills do they have? If you’re trying to get the best out of your team members, how would you go about it?
  19. 19. Just as we map risks, we should map what information each individual member of the team requires in order to do their job well.
  20. 20. But that’s not the end of the story. A Web product isn’t something you build and leave behind. Customer needs change, the business landscape changes; it is something that should rightly be in continual development.
  21. 21. How can we do it? Borrowing from the way of web 2.0.
  22. 22. The rise of “Web 2.0” (and henceforth, cloud computing) led to the need for change: • greater value placed on user-generated content • use and integration of APIs, leveraging existing social technologies • stronger emphasis (in theory) for the user This coincides with higher adoption of rapid application development, frequent release cycles, and agile/iterative methods.
  23. 23. An agile approach to projects • work as one team • work in short iterations • deliver on something each iteration • focus on business priorities • inspect and adapt Source: Michael Cohn, “Agile Estimating and Planning”
  24. 24. An agile approach to projects • manage uncertainty • accept the fact that we can only see clearly close in the future • acknowledge that beyond a certain point, we know very little Adapted from: Michael Cohn, “Agile Estimating and Planning”
  25. 25. Done well, agile methodologies can be creative, rewarding and productive. Executed badly, it becomes chaotic, and quality is compromised.
  26. 26. Unfortunately, agile methods traditionally rise only from application development ranks. It means that proper planning and inclusion for all the tasks leading up to development can be missing, mis-timed or just plainly assumed.
  27. 27. Activities that are likely to be iterative Art Direction Graphic design Branding UserX design Interface dev. Application dev. Analysis Content production QA & Testing Deployment Client User needs needs
  28. 28. How can we plan for uncertainty? Some techniques for estimation.
  29. 29. User stories “A user story is a software system requirement formulated as one or two sentences in the everyday or business language of the user. [...] User stories are a quick way of handling customer requirements without having to elaborate vast formalized requirement documents and without performing overloaded administrative tasks related to maintaining them. The intention with the user story is to be able to respond faster and with less overhead to rapidly changing real-world requirements.” Source: http://en.wikipedia.org/wiki/User_story
  30. 30. Example user stories • As a user, I can find available flights on the dates I want to travel. • As a user, I can find information about cruises based on my city of departure and intended destination. • As a regular user of the site, I can choose to receive news on specials offers on travel fares.
  31. 31. User stories ... • are unhindered expressions of key requirements • allow for a “top down” approach in defining what needs to be built • allow a team of diverse skills and viewpoints to identify what the requirement means to them. • better definition and clarity of priority
  32. 32. Task estimation techniques (for development) • “small enough to fit” • relative story points and velocity • include a margin for error and time for re-visiting estimates • the human element
  33. 33. Small enough to fit • choose an atom size for task: a unit of 4 hours • break all the definition tasks down until they fit the unit • understand that as details and specific are available, estimates may change.
  34. 34. Relative point size & velocity • choose an atom size for an average task • define tasks relative to atom size • velocity = measure of how many points you can complete in a real time frame • we get better and better at estimating velocity as time passes Source: Michael Cohn, “Agile Estimating and Planning”
  35. 35. Dog points How would you rank the height of dogs? Breed Dog points Labrador Terrier 5 Terrier 3 Great Dane 10 Poodle 3 Dachshund 1 German shepherd 5 Saint Bernard 9 Bulldog 3 Source: Michael Cohn, “Agile Estimating and Planning”
  36. 36. Estimating, the human way • A clear understanding of who’s on your team, and how they work • The person doing the job should estimate how long it should take • Buffering for optimism
  37. 37. Estimating, the human way • Creating individual accountability • Identify how to help each other fulfil our individual accountability
  38. 38. Summary
  39. 39. For a process to be successful, everyone on the team (including the stakeholders) needs to buy in and believe it. means the process cannot be external to the project, nor should it be separate from the formation of the team.
  40. 40. Acknowledge that each team member has a capacity for creativity and problem solving.
  41. 41. Ditch the cogwheel mentality.
  42. 42. Create and nurture a team culture of supporting one another in individual accountability.
  43. 43. The best work comes from passion and a sense of pride.
  44. 44. Thank you! Questions? Stephanie Troeth hello@stephanietroeth.com

×