I’ve run a few conferences… (BarCamp Vancouver, BarCamp Shanghai, BarCampLA 3, 4 & 5, DrupalCamp Seattle 2006, DrupalCampLA 2007 & 2008, CloudCamp Seattle)
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.
I’ve been working in (and evangelizing) Drupal since 2006 and I don’t plan to stop.
I’m also a fan of: great design, accessibility, open standards, and security.
Good projects require a lot of communication. There’s no
Clients are the experts on their needs, but you’re 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 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.
Process Someone should be the “owner” of every piece of the project. If you don’t know who it is, it’s probably you.
Standard sequential design and development process that relies on phases to be completed before beginning the next phase.
Construction (AKA implementation or coding)
Testing and debugging (AKA Validation)
Agile VS Waterfall Agile: User-centric social networking sites Web Apps Waterfall Corporate Sites and other informational sites, even with interactivity
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.”
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:
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.
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.
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.
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.
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.
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.
Be constantly clear on:
What you’re going to do
Every single deadline (give them the full schedule, to the hour, at least a week in advance)
WHY this project is important
And if you can (or still want to) plant the ideas for the next opportunity to work together
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.