Panel of the people on this page, also listed below. Sorry for lack of attribution for each comment!

How has managing a Drupal firm changed over the years?

• the focus of a firm is often inward; as Drupal has changed they’ve had to shift to focus outward. As Drupal grows, community grows and you have to be a part of it in order to be successful. Volacci has a partner program where they form relationships with other shops, build and nurture relationships as communities grow
• Used to have to sell Drupal to clients harder, but that’s eroded and changed over time - people started calling them
• As Drupal shops start to appear & Drupal gets higher profile, more competition forces shops to innovate and do things better

What are some of the best decisions you’ve made in your shops?

• working with Drupal is the obvious one
• team relocated from small town in Virginia to a larger city - able to attract and maintain good talent more easily
• a different attitude towards telecommuting
• process is important, but it’s also important to show your clients how your internal processes add value for them
• focus a lot of time on getting team to dance well together - it’s expensive, but everyone who comes into Development Seed gets Getting Things Done and Made To Stick. It’s very difficult if you don’t create a culture, have a consistent base within your organization, creating a GTD culture and having a common lexicon. Two other books for management specifically: Good to Great (prevent burnout!) and Getting to Yes (help decision making process as a team)

Context

• Eric Gunderson, Development Seed: 17 people
• Dave Terry, MediaCurrent, 12 employees, started focusing on Drupal in Fall 2007
• Jon Clark, design group, 6 member team, denver, 4 years in Drupal
• Ben Finklea, Volacci, 60 person firm in Austin
• Jeff Walpole, Phase 2, 32 people, founded in 2001, Washington DC
• Glenn Hilton, ImageX, 12 full time, founded 2001, started Drupal in 2005

Where do you go to recruit good people?

• As an owner, start with culture and vision of the company
• Get a lot of great people from Craigslist - Volacci finds lots of people who do good stuff that’s not Drupal specific well and teach them Drupal
• determine what percentage of management time is appropriate to dedicate to recruitment
• get the wrong people off the bus, get the right people on the bus.
• Always be recruiting, always on the look out
• Keep feeding work to freelancers and look for people to bring onto your team
• Read a book called Who
• call up colleagues & other companies to see if they have good leads on new talent

How to retain employees over time?

• find good fits, self-motivated communicators
• foster a good work culture & environment
• client work is training; product work can be more rewarding. Product culture is essential for staying sane.
• Need to find good structure early on for crafting contracts
• Development Seed basically fix prices solutions that they deliver, which is terrifying.
• Figure out a way to fix scope and be stubborn with clients
• It’s your job as a manager to facilitate your team; crazy client stuff will break down your team
• key to keeping employees is the direct relationship with owner or supervisor - that’s what will make them stay or leave. That comes down to communication. High salaries won’t do it.
• One perk: $2500 per year tuition or education reimbursement. Continuing education is a bigger perk and advantage than money. Send people to DrupalCamps and DrupalCons, get books, etc. Ask for knowledge share in return - e.g. 15 minute debrief at staff meeting.
• Culture of open communication and truly open debate. Not just token opinions, but real debates that change the way company works fosters ownership.
• Hire slowly, fire fast - don’t keep people who don’t work well.
• Volacci has no vacation policy - don’t track vacation, yet to have anyone abuse that. Go as long as you want to, but don’t drop the ball and get your work done. Have a weekly Volacci University - someone teaches a 30 minute course to the company on anything they want. Every Friday is WIFLE - What I Feel Like Expressing - each person has an opportunity to express anything they feel like expressing. No one can talk while you’re talking, everyone thanks each other for sharing, opportunity to get issues out and off chest. Rule that you leave it in the WIFLE. Also have weekly kudos meeting. When you get a kudo, you get to take a Pez dispenser from anyone in the room white elephant style

What’s the most useful technique for getting/increasing sales?

• Must create relevant, fresh content - blogging, white papers, whatever
• Form partnerships and alliances. Some of your best projects will come from other Drupal firms. Outreach to larger firms, ask for their leftovers, work on smaller projects which lead to bigger engagements and form alliances
• Contribute back to the Drupal community
• Blog posts take time, need to be strategic. You can make concrete, specific posts about technical problems and how they’ve been solved
• Errant volume in sales is as destructive as errant volume in recruiting. Better to grow slowly to get the right sales and the right clients, otherwise you’ll lose focus and go where they want to go and not where you want to go.
• Find a niche and be the best possible firm in that niche

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.