WestCoast2008:PM Principles - Advanced Web Projects

Notetaker: Tom

[Lessons Learned/Elevator Advice]

 - Tanya Africa (MoveOn)
   * Electoral Get Out The Vote software
   * Programmers say that a <something> tool will break, listen to them!
 - Debbie
   * Need staff buy-in
 - Lisa (Sigma Consulting)
   * Listen (x3) & talk to stakeholders
 - Michelle (quilted)
   * Make sure everyone on same page from start (scope, esp.)
 - An Chow (Dreamfish)
   * Ditto above)
 - Harvey
   * Know stakeholders
   * Workflow improvement
 - Andre (Rockford)
   * Astonished at proliferation (& pace of) tools and keeping track is tough
 - Dan (Maplite.org)
   * Make graphical mockup of UI early!!  Helps get support :)
 - Karen (Sophia's Garden)
   * Stay true to your vision but be flexible in implementation
 - Katherine
   * Clear requirements otherwise you'll solve the wrong problem
 - Ben
   * Mockup early!! Building in reflection early & often!!
 - Tom
   * Be sure to get right reqs.
 - Arthur (energy action)
   * Mockups: get specific tangible instead of moving forward before full talk-through
 - David (Radical Designs)
   * x4 -- x100 hours quote by devs!!  Educate client on impact of scope change are (exponential & how late changes are even *worse*)

 - Dan: find that outlining features & future ideas to enable devs to dev better
 - David: much pain comes from a lack of frontloading & planning
   * Heard some tools & tactics
 - Lisa: Challenge to convince org to spend resources on frontloading is tough.  Purchase something before deciding on what is needed.  tough to get investment in planning.
 - Harvey: We need this solved!! Ask why :)  Gotta know on the very basic level of who is going to use the software and *HOW*.  Gotta fill the needs of end users.  Get all stakeholders involved early
 - Tanya: One solution is to gather stakeholders.  Having the meeting will trick people into planning!  Panic button option: demo how if feature Q doesn't work, here's what will happen.  Use one good example!
 - Tom: Give clients the "wrong" option so they come back with the right one.
 - Arthur: Give the mockup so people can form opinions
 - Ben: Me Too
 - Karen: Turned a tech matrix into a mindmap.  Then used it to identify users and what functions mapped to users.  Combination of user story with tech matrix.  Easier to use graphical elements (like icons) to visually represent features and concepts and relations.  Want to ensure people *understand*
 - Harvey: Started document when had a personal lull and that forced people to create a timeframe & team.  Needed to get something out there in order to get people to start thinking about this sort of thing.  Several teams need to collaborate on a regular basis!!  Team A needs Team  B to finish their part before they can continue.  Ownership over a given feature does not mean complete independence.
 - David: Lots tools to kickstart process
   * Initial Planning Doc
   * UI Mockups
   * User Stories
   * Technology matrices
   * Timelines / Dependencies
   * Core Features Identification
   * Scoping the Planning Process
   * Decision Timeline & Ownership
   * Mapping out roles of the team
 - Tanya: Scoping Planning Process turns into planning the program & need to demand some early decision making.  Use standard doc that describes programmatic model as a living doc.  Becomes an authoratative reference for the *program*
 - Debbie: Decision timeline & ownership to figure out *who* has to be at which meetings and what the timeframes are
 - Lisa: Have a project champion who is responsible for keeping on timeline.  If 1 person falls behind it affects the whole project
 - Tom: Keep 'em focused on one project
 - Lisa: CEO, ED, etc. -- someone who has decision-making authority but isn't involved in implementation of project makes great project champion.

 - Ben: Mapping out roles of the team.  How to do this & what is the "right" amount of detail and how to get buy-in
 - Harvey: Initial research & getting down to the nitty-gritty of stakeholders & workflows is important to figure out *WHAT* is important and can filter through all of what you've gathered.  This then informs who you're going to have involved.  That way you have someone who you can go talk to about a particular feature.  Once you start implementation it's a wild bronco & it's OK to step out if something isn't working well.  But if you're implementing, you need to be happy with where you are.
 - Tanya: What *are* roles?
 - Ben: High Level like who is decision maker through low-level who is implementing a particular detail.  In successful projects I've experienced there have been explicitly and implicit roles defined.  This informs how they'll step up to fill a role.  Not strict guidelines on definition.
 - David: Points of Failure for is role definition.  Going higher & higher up will end up with irrelevant feedback, so need to know who to talk to at what *point* in the process.  Document who needs to sign off on *what* *when*.  UI changes late in the game due to feedback from CEO.  Ensure that you *know* who needs to sign off on what, when (decision matrix).  Sign off on design early & then don't get feedback until late in the game which creates problems.  So: establish roles *AND* timelines.
 - Andre: From client side this makes sense & you can't get involved enough in how the organization works.  You have to be an anthropologist.  Project failure is often based in the mysterious inner workings of the way the org works.  How willing & able are you to get inside or to prevent these breakdowns.
 - David: Depends on budget :)  NP Tech Dev is org. dev!  Can go in and do the org. dev & research *IFF* org has resources and are able to change in order to resolve particular tech issues.  Sometimes you can't do anything about the politics of the org in order to solve a tech problem.  (i.e. Hey, you should redefine your departments in order to solve this problem!).  Sometimes the technologist is the respected authority.
 - Andre: Ask org to let you present to the *whole* group.  Get the outliers who are going to sabotage later will make themselves known!
 - Eric: In consulting role, I set things up like that big group.  Get as many people there in order to figure out who plays what role internally.  That means that later you can have backchannel conversations in order to work out a problem.  Can figure out ahead of time who might derail process.  Sometimes my scoping won't predict entire cost because I need to do more work outside of *tech* work with back-channel conversations.

 - David: Budgeting process around tech planning is fairly elastic, but *goal* is often fixed-cost for non-profits.  How do you budget & manage expectations for the needs assessment.
 - Harvey: How many folks use scope triangle?
 - Some: What is it?
 - Harvey: Time vs. Quality vs. Money & pick any two :)  Get basic ideas on where you're going to end up through the simple exercise.
 - David: Many non-profits will turn it into a pentagon & make up two points :)
 - Lisa: As a client I'd ask the outsider to be your advocate for the project.  If you think there's a problem (i.e. sabotage) lemme know early so we can work together to figure it out.  Help me out on this sort of stuff!!
 - Dan: Fixed cost issue; I'm client & we've given up on fixed cost because we keep trying it and developers lose interest
 - Tom: Use ballparks in hourly.
 - Eric: I concur.  Often *fix* a planning component.  You can shop this project around out after the planning.  Then we throw out support costs and if they won't pay for that, I won't go into the project.  Don't wanna get caught in "site won't work without support"
 - Tanya: As a client we set a timeline that defines our budget & prioritize features based on timeline.  We identify tiers in order make sure certain features *do* get implemented.  Make sure programming team doesn't say "Are you from mars?!" on how feasible something is.  Can then guarantee that the tool will have these basic functions and no additional features and everything from there on *MUST* be prioritized.
 - Dan: How do you do QA & user testing.
 - David: Make the site live :p  If core basic functions work, you can launch.  As we've moved to SAS, we call the whole thing a beta indefinitely.  Depends on mission-critical functionality (i.e. if accounting, then this won't work), but if it's a web-app the user-experience will dictate priorities.  Won't know how (e.g. a social networking app) will work until real users use it.  Dev time for QA will be reasonable to quote for test-driven development.  When you write a chunk of code that does X, you write a test to check to make sure that the chunk of code does indeed do X.  2:1 test coverage (or some big ratio).  You *must* do something along those lines for large apps is pretty key.  Expressing this to client that it will make it successful down the line but cost more now is very tough.
 - Dan: So you ask devs to use it?
 - Katherine: Yup.  Very time-consuming and uses more resources you need to do it!
 - Michelle: From dev's view it's toughest when you *want* to do it and client doesn't have the buy in ("We don't see return on our $$").  You have features & write tests for features.  You should go the opposite way & write test first.
 - Tanya: Two questions -- when you write code to test it...how do you know it broke?
 - David: You run code & get feedback each time you change.
 - Katherine: You get a report along way
 - Tanya: As PM I feel like it'd be great to be able to explain this to program side...do you have examples & fact sheets?
 - Eric: Haven't seen fact sheet along those lines.  I've only done it once, but I've had a big problem in explaining it to client.  We set up a failure w/out test-driven code and we showed how this wouldn't happen in test-driven code.  Set it up for failure intentionally in order to drive the concept home!!  Hard to get them to buy in to 2x the code or 10x the code
 - Michelle: It's like insurance nothing ever seems to happen :)
 - David: Best practices dictate test-driven dev.  Build 1st, optimize later.  Scaling in large apps, you don't optimize from beginning.  Lots of tough decisions about how to make things work for massive numbers of users.  Hard to predict what will break.  These items are very tough to explain to client.
 - Michelle: It's hard to predict what will scale, but at the same time you don't want to go live & then have the site go down (!).  It's important to be able to test as you build out.  Hard to coordinate.
 - Tom: Sometimes if you're going to get lots of users at the outset, there's data you can pull from.
 - Arthur: Keep things simple & don't add things just because they're "nice to have".  When we get too complex our projects tend to fail.
 - Michelle: That ties in to staying true to vision.  As you start developing you often lose sight of what is mission-critical.  Staying simple & streamlined is excellent.
 - Harvey: This is a reason why to get stakeholders together in order to inform the developers of what needs to be improved.  There *will* be changes, but both sides will need to consider technical & political sides.
 - Karen: Spoke with community manager who said launch with simple feature set and then get early user feedback and you'll then be able to figure out what is necessary.  Test that what you've planed is what the users want?
 - Tom: How do you convince client of this?
 - Lisa: I'm in that situation.  It's easier to *build* credibility than to *re*-build it.  If you do a little at a time, you build slower.
 - Andre: From the client side, we want to present a good face to people all at once.  We want to get success with the swarm phenomenon.  It's tough to buy in for beta-testing.
 - Karen: I worked *very* closely with a developer on a site and I'm *very* invested with the site now!!  In a year they'll have a great product.  So it's was good for me to have that experience and understand the way the process works and this is a developing mindset.