<ul><li>So, who am I? </li></ul><ul><li>I’ve
run a few conferences… (BarCamp Vancouver, BarCamp Shanghai, BarCampLA 3, 4 & 5, DrupalCamp Seattle 2006, DrupalCampLA 2007 & 2008, CloudCamp Seattle) </li></ul><ul><li>I’ve contributed User Experience Design and Project Management to projects for MySpace Mobile, Hearst Magazines, Fonality, Nonesuch Records, Wasserman Media Group, Logitech, Symantec, Metallica, and Madonna. </li></ul><ul><li>I’ve been working in (and evangelizing) Drupal since 2006 and I don’t plan to stop. </li></ul><ul><li>I’m also a fan of: great design, accessibility, open standards, and security. </li></ul>
<ul><li>Where do great websites come
from? </li></ul><ul><li>Planning </li></ul><ul><li>Talent </li></ul><ul><li>Great Clients </li></ul><ul><li>(you may only have control over #1, so work with it) </li></ul>
<ul><li>The Talking Stage </li></ul><ul><li>Good projects
require a lot of communication. There’s no </li></ul><ul><li>shortcut. </li></ul><ul><li>Clients are the experts on their needs, but you’re the expert on </li></ul><ul><li>getting them there. Show what you know, but listen. </li></ul><ul><li>You can’t afford to save time on planning or communication. </li></ul>
Process Your process is your
toolbox. Keep it light enough to be agile, but it should provide structure. Process should minimize the “…and what now?” and the “where is that file?” and the “when is it due?” questions. If it doesn’t, re-examine until you have a structural ecosystem that works. If it gets in the way, don’t be afraid to try something lighter.
<ul><li>What is agile? </li></ul><ul><li>The primary
focus of agile methodology is defined in the four main bullet points of the Agile manifesto: </li></ul><ul><li>Individuals and interactions over processes and tools </li></ul><ul><li>Working software over comprehensive documentation </li></ul><ul><li>Customer collaboration over contract negotiation </li></ul><ul><li>Responding to change over following a plan </li></ul>
<ul><li>What is Waterfall? </li></ul><ul><li>Standard sequential
design and development process that relies on phases to be completed before beginning the next phase. </li></ul><ul><li>Requirements specification </li></ul><ul><li>Design </li></ul><ul><li>Construction (AKA implementation or coding) </li></ul><ul><li>Integration </li></ul><ul><li>Testing and debugging (AKA Validation) </li></ul><ul><li>Installation </li></ul><ul><li>Maintenance </li></ul>
Agile Requires EXTREMELY talented and
motivated developers Constant access to design resources . Progressive clients who are willing to invest continuous resources in the project and actively THINK about the direction . If you lack any of the above, plan well, lock it down with wireframes and milestones and proceed.
And even with agile, wireframes
are a good place to start – you just get to responsibly override them if needs change. (you can do the same with waterfall if it makes sense for all involved)
Estimating Estimating is hard. CivicActions
just released a lovely tool, maintained by Owen Barton, from their own process at: http://civicactions.com/estimating-worksheet They also provide some excellent advice. Some of my favorite points…
From CivicActions… “ Think about,
and state each assumption you make when estimating.” “ Estimate each area of work (engineering, theming, configuration, communication) separately, and make sure you include adequate time for communication, both with the client to clarify the requirements, and also internal communication between team members.” “ If the work includes new, untested code, e.g., writing a new module or including a (non-standard) contrib module, add time in the estimate for unit testing which could include the writing of simpletests and flag this to the QA team as a place that will require additional QA.”
“ Vary the amount or
research with the size of the line item - if you are not sure about something, but it would only take 5 hours to build from scratch, just put 5 hours - if you need to integrate with some 3rd party system, and it might be a weeks work make sure that you understand the requirements very well (ask the client questions to clarify where needed) and research things fully.” “ Never (ever!) estimate 'to' a budget - your estimates for each line item should disregard any information we have about the available budget. Instead think purely in terms of how long it will take to get the job done. If the hours exceed the budget we will discuss a reduced feature set (at least initially) with the client. If the overall costs look like they will massively exceed the budget then ask the client to prioritize first and estimate a subset of the items.”
<ul><li>Scheduling </li></ul><ul><li>When its time to
make that magical “this is how and when it’s going to get done” document, just keep the following points in mind: </li></ul><ul><li>The mythical man-hour – A task that takes one person 8 hours does not necessarily take 2 people 4 hours. Allow for ramp time and knowledge transfer. </li></ul><ul><li>Order of Operations – Theming can’t start until design is delivered, many QA tasks don’t make sense until the theme is completed, etc. Remember to look for possible gaps caused by dependencies and see where you can schedule tasks to counter them. </li></ul><ul><li>Client Approval Time – Remember to give clients ample time to review and submit feedback – otherwise you’ll see delays and/or unnecessary extra rounds of changes. </li></ul>
Design Design matters. A lot.
Most people won’t know the site is built on Drupal – nor will they care. They will, however, notice the design and usability of the site. Invest in these things – budget and schedule for them. Push for best practices and innovative designs with your clients. Just because there IS a default design for an element in Drupal doesn’t mean it’s appropriate to use it. Improving the overall aesthetics of sites built on Drupal is crucial to the growth and sustainability of the platform and the community, and few have more power to make that change than the project managers.
<ul><li>Toolbox </li></ul><ul><li>Scheduling, gantt charts –
Merlin, MS Project </li></ul><ul><li>Wireframes and Sitemaps – Omnigraffle, Visio </li></ul><ul><li>Shared notes, estimation worksheets, proposal drafts – Intranet, Wikis, Google Docs </li></ul><ul><li>Task and time tracking – Basecamp, Unfuddle, Storm, Harvest, LiquidPlanner, dozens more. Most not so good. </li></ul><ul><li>Bug tracking – Mantis, trac, JIRA, case tracker module, many. </li></ul><ul><li>Code Review – Crucible </li></ul><ul><li>Whiteboards (physical ones) </li></ul><ul><li>Skype/IM – use sparingly for important communication and never for critique </li></ul><ul><li>The Phone (Don’t ignore this one – it works shockingly well) </li></ul>
Great Projects do Not Happen
In Spite of Bad Clients Good projects can, but truly world-class work that you want to show everyone takes clients who ‘get it’ – and are stable enough to support their end of the deal. Know who to say “No” to .
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 for $__” “ My neighbor says…”
Good Clients Know They’re Investing
Some Basic Qualifying Questions Immediate goal or critical business issue. Is there a good reason for this project? Can they articulate it? Budget: what is this budget for the project or the estimated cost of the solution? Have they budgeted ample funds for their scope? Ambition is good, all clients SHOULD want a little more than they have funds for. Timeline. When does the project need to go live? Is it reasonable? Is there an external event that drives that date? Key metrics of success? Who decides them? It’s important for all involved to have a solid idea of the goals for the project – otherwise they will not be reached.
<ul><li>Basic Client Management </li></ul><ul><li>Advice from
Baseball - Keep your eyes on the ball and keep it front of you </li></ul><ul><li>Have a central contact and make sure that person is vetting everything through all necessary stakeholders. </li></ul><ul><li>You are now the General for the web aspect of their brand – act like it. Do well, and you’ll have their trust. </li></ul><ul><li>This means: </li></ul><ul><li>Demonstrating expertise </li></ul><ul><li>Doing your research and knowing their market, their objectives, and their history </li></ul><ul><li>Providing real value and expertise that results in quantifiable wins for them (keep an eye on that data!) </li></ul><ul><li>Bringing your A-game and delivering on schedule </li></ul>
<ul><li>“ But it needs to
happen NOW” </li></ul><ul><li>Urgency is a factor in this business – it just is. A few strategies for dealing. </li></ul><ul><li>Know the limits of your team – don’t over promise </li></ul><ul><li>Determine the reason for the urgency, if it’s valid, and whether a compromise can be reached that makes sense </li></ul><ul><li>More budget doesn’t always help (some projects can’t be distributed) – but if it does, present the option and be prepared to take it </li></ul><ul><li>Have a plan. Schedule everything. Show WHY you need the time you do </li></ul><ul><li>Something WILL go wrong. PLAN FOR IT. </li></ul>
<ul><li>Manage Expectations (with an Iron
Grip) </li></ul><ul><li>Even more so than most clients, high profile projects or ones on a tight schedule need as much repetition as you and your client can stomach. </li></ul><ul><li>Be constantly clear on: </li></ul><ul><li>What you’re going to do </li></ul><ul><li>Every single deadline (give them the full schedule, to the hour, at least a week in advance) </li></ul><ul><li>WHY this project is important </li></ul><ul><li>And if you can (or still want to) plant the ideas for the next opportunity to work together </li></ul>
How to Say No Sometimes
you have to say no. This doesn’t have to be a painful thing. Voice your concerns early – and calmly. Have good reasons and appeal to business reasons that matter to them. Example: Forked Modules Protect your team – this sometimes involves heavily managed expectations, which usually means lots of saying ‘no’ Be ready to offer alternative options – be HELPFUL LISTEN to their reasons and understand the pain they need met – their request may not be reasonable, but there may be other alternatives.
“ Bless and Release” When
all else fails – it’s OK to end it. Bad business is bad for ALL of your business. Letting one client pollute the overall mindset of your team is toxic . Be open with the client about where and why your business relationship isn’t working. If compromises can’t be met – work out a way to refer them to someone who might be better suited, but keep the communication open.
Drupal Specifics Know your modules.
This takes time and constant investment – but it’s crucial for project planning. Consider setting up a regular time for your team to review what’s new and good (or not so good) out there Consider balancing your development load across developers and non developers for site configuration tasks. Get a consistent method for initial site configuration. Work closely with IA/UE Designers so that they know what’s possible with Drupal. The taxonomy system and Views make functionality possible on Drupal sites that would be prohibitively expensive to build elsewhere. Know how it works. Give Back.