The Glue: How to Stick a Drupal Project with Project Management

Editor's Notes

• #3: Hi, I’m Susan and I’m a project manager at Chapter three. I’ve been managing web projects for aboutdecadein that time I have filled many roles owning a Drupal agency (included a lot of sales and books) doing development marketing websites managing webprojectsI discovered that my strength was in project management –being there to maintain continuity and momentum from the beginning to the end of a project.I’ve been managing Drupal projects for about six years. Tonight I’m going to share my experience and let you know what has worked for me and what hasn’t.I’ll run through the process of developing a Drupal site and point out the key things to be aware of at each stage.
• #4: Don’t say anything
• #5: Be Selective:If you have luxury of choosing your clients and your projects, do itIt’s one of the best ways to ensure successLook for client commitment and enthusiasmLook for clients that understand that their participation is integral to the success of the project (give them numbers to drive home this point, ex: 15 hours/week).Confirm that the client’s budget is inline with yours:Though you won’t be able to create an estimate until you do a full review of the project, you should have a very rough idea of how much a project will cost. If you know that a project of this general scope usually costs between $15,000 and $30,000, try to let your client know that. If they are expecting to pay $5,000, it’s not worth going much further.Make sure Drupal is the right platform:Drupal is not the right choice for every project. It’s is a front end that displays content. There are some thing it doesn’t do well. Some examples that I’ve heard are: Don’t use Drupal to implement a bank services api or use drupal to build out a data warehousePrior to coming to Chapter Three, I had my own drawn-out failure of a project – trying to create a single website that would conglomerate real estate feeds (RETS) and distribute property info to individual realtor websites, with a custom user registration system, property watch section and listing notifications. My partner and I had a lot of real estate clients and this site was going to be a slick, clean way to meet their needs. The implementation ended up requiring us to hack the existing RETS import module (dRealty), writing a lot of javascript to pass user information between parent sites and the child iframes, and essentially rewrite Drupal’s core User module. We kept losing developers and by the end no one would touch it. Our lead developer told me he wished he had done it in Ruby.With a year’s worth of work into it, we squashed it. It was painful, but it taught me an invaluable lesson: If the project that you’re considering involves overriding any of Drupal’s core modules for it’s basic functionality, don’t do it in Drupal – look elsewhere.So… once you have screened a client and confirmed these things, it’s time to move on to planning.
• #6: Client Survey / Meeting: Understand client goalsSaves you a lot of time - you don’t have to ask the same questions over and over. It also makes the client think about and take ownership of his or her own goals. If the survey or the questions in it turn the client off, it’s a sign that she may not be ready to move forwardI have had client return mostly blank documents, not send it back at all or take months to do soSite Map: examples in links on the next slide – serves as a foundation for the functional requirementsDetail the Functional Requirements: Summarizes the goals and requirements for the site. It should be extremely detailed as possible and use examples. Do this from a user perspective. “User A wants to be able to add an event to the calendar”Don’t be afraid to ask (silly) questions. If you don’t understand something now, you probably won’t later and it’s possible that your client hasn’t fully thought it through.ADDRESS RISKS – what is not explicit? What may take longer than first thought. Recent example of a piece of site registration functionality that the client was adamant about. The devs knew it would be difficult and not worth the time in terms of user experience. the client wouldn’t budge and somehow this made it into the project (the SOW was done under a previous project manager) – it was line itemed, but the risks weren’t addressed and it took much longer than expected. It sucked a lot of time and energy out of the team and sadly, after all that time getting it work, the client has decided to remove it. Addressing the risk up front might have expedited that decision.If the functional requirements can’t be completely detailed because you’re using an agile process, be very clear that the budget is not fixed and that the scope will change as the project progresses.Outline the Technical Requirements: Ask your team (devs, designers, content strategists, etc) to help you understand what is required technically in order to accomplish the functional requirements. Create a spreadsheet with each bit of functionality and ask them to note what technology they might use to accomplish it, along with the number of hours or days they estimate it might Now is the chance to get team buy-in, which is as important as client buy in.Ask your designers and developers to tell you when a requirement seems like it doesn’t make sense, doesn’t follow best practices, would require a disproportionate amount of work. Ask if they have a better solution? Communicate to the client and see if the functional requirements can be changed.Scope of Work: Detailed and thorough and based directly on the functional and technical requirements. Include a line item for each part of the project (design, content strategy, theming, development, project management, quality assurance and server costs and support if applicable). PAD YOUR ESTIMATES, include QA time and PM time.Mention risks and anything that might need to be change ordered if anything else changes. Include a project timeline based on a schedule of client deliverables and team projections. (examples on next slide)Have someone on your team carefully proofread this document. It will lock in the scope and it’s important to get it right.Get sign-offKick off meeting (some notes on running a good meeting later)Break the Scope of Work into Tasks for your Team: make sure to include deadlines, details, links to important graphics and details. (specific PM SW discussion later)
• #7: Where the design team turns the requirements into a visual representation of the user interface. It usually starts with wireframes. Educate the client on exactly what the design process will include and what additional costs will be incurred for continued design revisions. The design team will consider the size of the files on your site and page load time – 2 seconds or less – communicate best practices – mention recent project where that wasn’t adhered to (external design team) – it looks great, but performance suffered as evidenced by a crazy bounce rate of sometimes 80% or greater (this is a big site!)Template approach: a Fireworks template that ensures that all Drupal specific elements are styled. The beauty of Drupal is not having to reinvent the wheel. This takes it beyond functionality and into the design realm.
• #8: This is when the designs are signed off on and theming and development can begin Don’t use Drupal tech talk when talking to your clients about Drupal, do use it when talking to developers. If you dpn’t come from a Drupal background, take a class, read a book, make a Drupal site or two. Get comfortable with the basic terms: (Core, Contrib, Node, Field, Block, Content Type, Taxonomy, Users, Roles, Permissions, Module, View, Theme, Template Files)Specify the users, roles, taxonomies, imagecache settings, etcStay closely in touch with your developers as they implement the technical requirements, track progressRemove obstacles. If the client is holding up the process, let them know. If another project manager is making demands on the developers time, have a conversation with the PM. The first step if often to find the obstacles, then see what can be done about them.
• #9: Entering ContentBefore design and development begins,try to get three to five examples of each type of content. Working with real content is critical to designing, developing and testing.Clients usually don’t have content (or know how to generate content) until the site is mostly built and designers and developers usually can’t build the site without the content (at least not without having to make significant changes as the content evolves). So the ideal situation is to enter test content as soon as possible during development and then enter all final content after development and before QA. This rarely happens, but do your best. Try to advise your stakeholders about the risks of entering content at the last minute (could cause additional development time and delays).Training Site AdminsMy tried and true method is to make a list of all of the tasks that the site administrator will need to perform. I create a document and listthrough each task, outline the steps to take and include annotated screenshots to make sure that everything is crystal clear. Review the documents for accuracy, send it to the client, ask them to review it and then schedule a meeting for them to follow the documentation and enter the content – make sure you let them “drive”.
• #11: Make checklists to make sure you cover everythingWe recently completed a project where the scope continued to change through the project and there’s wasn’t enough time to perform adequate QA before the launch deadline, resulting in frustration all around.The lesson was that if a particular part of the timeline gets pushed out (designs are late, etc) the rest of the timeline needs to get pushed to make sure that QA doesn’t get skipped or move until after launch!Prep the client for ongoing support well before launch.Leave twice as long as you think it will take for launch
• #12: Scope creep is inevitable – it needs to be handled firmly and with finesse. Scope creep is when requests come in that are outside of the scope of the project, that is, they were not explicitly included in the requirements and detailed in the technical specifications. It is important for the project manager to label such requests as out of scope immediately. It may be tempting to just do them because they seems simple, quick or like they would enhance the site, it’s important to set them aside and outline them as change requests or Phase II.Use a calm and professional tone when negotiating out-of-scope changes, this sets the stage for the client to respond in suit. Try to setup a give and take situation.If a client insists that out of scope changes are in scope, illustrate why scope changes take more time (use examples, use samples, show evidence, show don’t tell, make them understand)
• #13: Honesty & Transparency: Honesty builds credibility.It secures your role as a trusted advisor. There’s less to remember.Let your client know if you can’t do something or you think that something is not a good idea. Don’t be afraid to say no politely. Your clients and your team should respect you for it. If you don’t know the answer to a client question? Be honest. Tell her that you don’t know and you’ll find out the answer and get back to her. Do the research. Ask for help. Use the opportunity to educate yourself.Listen & Mirror:people want to be heard: listen and mirror (repeat back what you have heard)don’t be defensiveabsorb, don’t reflect frustrationuse bulleted lists to summarize meetings, big chunks of work, change requestsPrioritization! Developers will have an idea of the order in which tasks should be tackled, but you may find that the client is eager to see a particular feature implemented earlier on in the process. In this case, it’s important to have the client prioritize the tasks. You can also use this as a tool to underscore the limitations of the resources (sure we can get the blog up and running this week, but keep in mind that it will push development of the events calendar until next week)Tracking Time and MoneyCreate and review weekly time and task reports. If looks like it might exceed the budget, take a step back and talk with the team about why that might be and what could be done to get things back on track. Conduct weekly meetings with the design and development teams to review tasks and discuss priorities. This helps maintain flow and address any concerns or obstacles. Get Official Sign offOn the requirements documentOn wireframesOn designsOn the Beta site once it has been tested and is ready for launchManage ExpectationsIf something is going to be delayed, or you suspect something might not go as planned, or that your client’s expectations are out of line with your teams, let the client know what to expect. Doing this up front is much better than waiting to see what happens.
• #14: If content is king for search, then communication is king for project management. I used the word glue in the title of this this presentation, and for a while that’s how I summarizedmy role as a PM, but I realized that it’s more like flow than glue – it’s a fluid process in which the PM floats along with the project, maintains momentum and make sure everything keeps flowing smoothly downstream.  Frequent, thorough and clear communication with your clients, accounting team, designers and developers is very important.Be sure to use all mediums: email, phone, instant messenger, project management software, meetings, screen shares, etc.I’m an email person, and I used to be somewhat reluctant to pick up the phone because I thought that everything looked ok on the screen Each time I picked up the phone or called a meeting, it brought up issues or questions that didn’t come out in email and often clarified questions that we didn’t even know we had. When you can read body language or listen to tone, it smooths out communications and helps us remember that we’re all human and we’re all working toward the same goal. Be available. So that your client feels like her concerns are at the forefront of your attention and that her needs and wants are important.  Be Responsive: Reply to emails quickly to let your client know that the email was received and that you are looking into the issue.Frequently emphasize your progress and the positive direction of the project
• #15: Thanks to Aimee and Kristen of Hook42 for this:FeaturesTime tracking for PSO shops (by task)Document, bug, task trackingInternal vs. External visibility to some itemsNo cap for client users and 1099sIntegration to Dropbox / Google AppsEmail creation of tasks and bugs ArchivalUnlimited # of projects on a system.Mobile app support (for time / task entry)Exportable timesheets (for invoicing)Integration of client address listImport of a project schedule.Cost comparison:Your time costs money, but if you have more time than money, red mine is great.Don't get hosed with incremental user costsDon't get hosed with # of projects – you sometimes may want a ton of little projectsWe looked at:Base camp (the new one didn't have time tracking at the time)Teamwork (cost maybe for us?)Do (Adobe)Wrike (was ok, but didn't feel good)Hosted Redmine (too expensive for amount of features)Atlassian (too expensive per seat)Zoho (has integrations to tons of things) <-- best bang for buck (bugs + PM software), not all the way perfect, but has tons of things.