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

1. Realising dreams
Building for the web
Stephanie Troeth
November 24 2008
School of Information Studies
McGill University, Montreal.

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. Who’s responsible?
The myths of the role of the project manager,
the web producer, et al.

4. Observation #1
Role definition is
hard to find.
This should send us a warning signal.

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. 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. 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. 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. Observation #2
Consensus of roles does
not appear to exist.
This should send us another warning signal.

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. 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. The project manager or producer has the
task of balancing dream and reality in the
building of a web site.

13. What needs to be done?
The reality of what is required for us to build a good product.

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. 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. 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. Interdependence of project activities
Art Direction Graphic design
Branding UserX design Interface dev.
Application dev.
Analysis
Content
production
QA & Testing
Deployment

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. 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. 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. How can we do it?
Borrowing from the way of web 2.0.

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. 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. 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. Done well, agile methodologies can be
creative, rewarding and productive.
Executed badly, it becomes chaotic, and
quality is compromised.

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. 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. How can we plan for
uncertainty?
Some techniques for estimation.

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. 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. 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. 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. 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. 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. 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. 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. Estimating, the human way
• Creating individual accountability
• Identify how to help each other fulfil our
individual accountability

38. Summary

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. Acknowledge that each team member
has a capacity for creativity and
problem solving.

41. Ditch the cogwheel mentality.

42. Create and nurture a team culture of
supporting one another in individual
accountability.

43. The best work comes from passion and
a sense of pride.

44. Thank you!
Questions?
Stephanie Troeth
hello@stephanietroeth.com