You are hereBlogs / Jeff Schuler's blog / Project Management For Fun and Profit

Project Management For Fun and Profit


Posted by Jeff Schuler - on 06 March 2009

Project Management For Fun and Profit
Crystal Williams

The Talking Stage

  • There is no shortcut
  • Clients are the experts on their needs, though they don't always know how to express that, but your'e the expert on getting them there. Show what you know, but listen.
  • You can't afford to save time on planning or communication.

Process

  • Your toolbox: light and agile but provide structure
  • minimize the "what now?", "where is that file?", "when is it due?"
  • re-examine until you have structure works
  • there should be an owner for every piece: if you're a PM, try to make it not be you!

Agile vs/ Waterfall

  • Neither is appropriate for ALL projects or developers, so be careful.
  • Agile
    • has become a sacred cow in OSS community. Can be great when it works, but takes a lot from client
  • Waterfall: "standard" sequential design & dev process
  • Holy war...

Good for:

  • Agile
    • User-centric social networking sites, Web apps
  • Waterfall
    • Corporate Sites and other informational sites, even with interactivity

Agile Requirements

  • Extremely talented and motivated developers who know how to say No
  • Constant access to design resources
  • Progressive clients who are willing to invest continuous resources in the project and actively think about the direction

Even with Agile,

Estimating

  • is hard!
  • The CivicActions Estimating Worksheet
  • State assumptions
  • Estimate each area of work separately, and include adequate time for communication with client and internal, and testing
  • Never estimate "to" a budget: line items disregard available budget: how long to get the job done?
    • discuss a reduced feature set

Scheduling

  • Mythical man-hour: 8 hour task doesn't take 2 people 4 hours.
  • order of operations: gaps in dependencies
  • client approval time

Design

  • Clients don't care about Drupal. Design for their needs, and not for Drupal defaults.

Tools

  • scheduling: Merlin, MS Project
  • WIreframes and sitemaps: omnigraffle, Visio
  • Shared notes, estimation worksheets, proposal drafts: intranet, wikis, google docs
  • task and time tracking: basecamp, unfuddle, storm, harvest, LiquidPlanner, more more
  • Bug tracking: Mantis, Trac, JIRA, Case Tracker Module, many
  • Code Review: Crucible
  • Whiteboards (real)
  • Skype/IM : sparingly, and never for critique
  • Phone: don't ignore!

Clients

  • Great project do not happen in spite of bad clients
  • seek and cultivate great clients
  • Great work to show off takes clients who 'get it' -- and are stable enough to support their end of the deal.

Warning Signs

  • "I don't care, just get it done"
  • "I don't need project management"
  • "I need it this week"
  • "I could get a freelancer [in India] for $__"
  • "My neighbor, [who's an expert in this,] says..."

Good Clients know they're investing. Key questions

  • Immediate goal or cricital biz issue: reason for the project? can they articulate?
  • Budget: What's budget for the project or the estimated cost of solution? Ample funds for their scope? Ambition is good, but make sure they're stable.
  • Timeline: When does the project need to go live? External influences?
  • Key metrics of success? Who decides? They should be important to all.

Basic Client Management

  • Focus on goal
  • Have central contact and ensure they're vetting all through necessary stakeholders
  • You are the General for the web aspect of their brand: act it.
  • Demonstrate expertise
  • Know their market, etc
  • Provide real value

Urgency is a factor

  • Don't over-promise
  • Whas' the reason for the emergency?

Manage expectations...

The busier your contact, the more in advance you need to communicate what they owe you (in meetings, feedback, etc.)

How to say no

  • voice concerns early
  • protect your team

"Bless and release" : fire bad client -- avoid toxicity

Know your modules: difference between 10 minutes and 10 hours for a feature.

Blaance development load against developers and non-developers for site configuration tasks : consistent method for initial site configuration

Work closely with IA/UE designers so they know what's possible with Drupal. Taxonomy and Views make functionality possible on Drupal sites that would be prohibitively expensive to build elsewhere. Likewise, know how to suggest features you're [familiar with] to clients.

Give Back (to the community) -- many ways to do so...