Raw Notes: Planning and Executing a Successful Drupal Implementation

Presented by Michael Morris and Dave Leonard of Phase 2 Technology

How to work with stakeholders

• give people a proper introduction to Drupal - lots of weird terminology, figure out how to explain it clearly and properly
• explain open source - talk about the community, understanding what free means (as in speech, not just beer), make sure they understand that you might share the work you do for them with the community
• expalin that Drupal isn't magic - takes time, work to get a good site
• Set expectations properly - make sure you present realistic timeline, 3-5 month timeline is reasonable for most Drupal sites from start to true finish - QA, testing, fixes, content posted, etc
• Communicate effectively - recommend using tools like Basecamp or Open Atrium, have a project portal to communicate within team and with client. Supply status reports with regular updates about tasks completed, pending, late, to be started or completed. Have regular meetings with clients.
• Drupal can be difficult to grasp at times.
• Train stakeholders properly. In-person training is the best solution. Give administration guides, though find the balance; want to avoid too much documentation that will get stale. Minimalistic starter guides are a good approach. Short screencasts are also useful and can be linked up within admin interface itself.
• Encourage early stakeholder testing. Are the details right? Does it actually meet their needs? Want to find this stuff out earlier rather than later. No substitute for having site owners/users actually using it. "If you have a site launch in two weeks and your site owners haven't used it yet, you're probably in trouble." Does it look great (to the stakeholders)?
• Hard projects need stakeholder involvement. Make them part of the team, help them help themselves, hold them accountable for their own success - they'll be working hard on this site, too.

Executing on difficult Drupal projects

• Understand the Drupal learning curve. There's a wall you hit when you get into Drupal really deep; need to understand this so it doesn't surprise you mid-project. Prepare yourself for mistakes, learn from them.
• Put the right project team mix together: project manager involved through the entire course of the project - risk negation, status checks, accountable for stakeholder satisfaction; analyst to define requirements and do testing, transform needs into defined, achievable tasks; designer; web producer; developers (maybe 1-3, someone primary)
• Encourage role flexibility. Don't be a baseball team (each person only covering the immediate area around your position). Be more like a soccer team - follow "the ball" around, don't be afraid of taking on other areas
• Be agile and manage scope effectively. Look into actual Agile workflow. Set sprints, iteration goals and planning meetings, work through the project like that. Don't have to necessarily define everything up front; try to do it in chunks while managing scope effectively. Be firm on scope but flexible on features; prioritize properly, get the right things in first and push others into the backlog. Open backlogs up to your clients.
• Foster intra-team communication. Consistently use good task management tools (Phase2 uses Jira). Use real time communication.
• Insist on quality from team members: not buggy, not sloppy, everything covered.
• Hard projects need right team and good processes; have a multi-disciplined team that understands the Drupal ecosystem and an agile approach that allows for flexibility.

Defining scope and requirements

• Start digging! What are the site's goals? Who is the audience? What is the focus of the content? How do your editors work? What are other sites you like?
• Requirements toolbox: site map, wireframes, specs, system diagrams, design comps, user surveys, user stories, style tiles
• Create a site map to define the breadth of a site, navigation (primarily good for visualizing hierarchical navigation, not so much contextual navigation)
• Brainstorm and sketch layout ideas as a team
• Create detailed wireframes with detailed annotations; someone can look at them and really understand how their site is going to function.
• Don't neglect the details. Get all the way into the nitty-gritty in the upfront planning process to save time during the build out.
• Document integrations with system diagrams - how the site you're building integrates with the entire ecosystem of the organization (e.g. CRM tools, syndication, content import or export)
• Document the specifications somewhere where internal team and client can see it.
• Meet design expectations; wireframes often aren't enough to ensure client satisfaction with end results.
• Hard Drupal projects make defining requirements even more challenging. Use proven analysis techniques. Don't neglect details. Don't focus on just the website - think about the whole system.

Addressing common challenges

• Replace (clients') bad habits with good ones. Don't get surprised by old, leftover expectations about workflow.
• Structure content properly.
• Pay attention to permissions; sort out who is allowed to do what.
• Use taxonomy effectively.
• Present a clean admin interface and give clients a good editing experience. Use a WYSIWYG that works smoothly and properly.
• Allow editors to curate and innovate on their website, e.g. editors' choice features on the site that can be implemented easily by site editors.
• Provide for editorial workflows that work well, smoothly, allow for fine-grained control. Implement presets that anticipate how things will appear on the site.
• Represent content relationships correctly.
• Differentiate between authors and users as necessary. There might be multiple authors or non-user authors that the default Author field can't necessarily handle.
• Improve search with Apache SOLR - lots of big improvements, allows for great filters, bias search results
• Pay attention to roles and permissions.
• Migrate content accurately. Have a solid understanding of what they were doing in their old system so that you can carry legacy items over when they're needed. Check out Migrate and Table Wizard for as much of the heavy lifting as possible, but you may need to do some more cleanup work; the earlier you can evaluate the complications there, the better.
• Hard Drupal projects have a more diverse set of challenges to solve. Use Drupal features and functionality the right way. Meet the needs of editors and content writers. Solve problems with the right techniques.

Q&A

• Q: How much discovery in the sales process, pre-contract and payment? A: Learn as much as you can at the outset though set boundaries, sometimes need to charge for it. The more info you know, the better an estimate you can give your client for the project (timeline and cost)
• Q: Firm on scope, flexible on features? A: Give a budget estimate and try to stick with it; sometimes they do fixed price, sometimes they do time and materials. Have to bound the problem; be firm on scope so that if big huge things are introduced you can say no
• Implicit Q and A: site maps, wireframes, etc are packaged as deliverables, artifacts are visible to clients
• Q: How does training work? A: Usually build in training time; minimally do two big training sessions (2-3 hours) for each project, along with lots of preparation. Usually throw in 3-4 working days of training prep and delivery. Alpha release, training, then hand the keys over to clients for initial use and testing. No one gets site use access before the training session.
• Implicit Q and A: build analysis and discovery into the paid process of the site building, hope you made good estimates in the proposal process. If the estimates are off, gently ask for more money, try to reprioritize, slow down expectations so that they have a chance to see how a Drupal site works before adding on more features.