The document provides tips and best practices for project management of websites built with Drupal. It discusses the importance of planning, communication with clients, using an appropriate development process (agile vs waterfall), estimating timelines, scheduling tasks, prioritizing design, managing client expectations, and Drupal-specific considerations.

1. Project Management for Fun and Profit Crystal Williams VP Professional Services work habit

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

11. Process Someone should be the “owner” of every piece of the project. If you don’t know who it is, it’s probably you.

12. Try to keep it from being you.

13. Agile VS Waterfall Neither is appropriate for ALL projects or all developers, so be careful.

16. Agile VS Waterfall Agile: User-centric social networking sites Web Apps Waterfall Corporate Sites and other informational sites, even with interactivity

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

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

19. 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…

20. 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.”

21. “ 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.”

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

25. Clients The great unknown

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

27. 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…”

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

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

33. “ 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.

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

35. Questions? [email_address] @ccg