From DrupalCon Chicago 2011, Treehouse SVP, Operations, Nicole Lind joins colleagues from other top agencies to discuss approaches to managing enterprise-level Drupal projects. Questions answered by this session Question 1: How does PM involvement impact the various phases of a project and the organization... and should it? Question 2: How do you say "No" to the wrong type of work and still keep a positive client relationship? Question 3: How do you partner with clients to ensure the project needs are met? Question 4: Are there differences in managing Drupal projects versus other technology projects? Question 5: What are some shared tools to help navigate the questions being answered in this session?

1. Project Management As an Art Form DrupalCon Chicago 2011 Nicole Lind, Treehouse Agency, nlind@treehouseagency.com Joel Sackett, Phase 2 Technology, joel@phase2technology.com Amy O’Malley, Palantir.net, omalley@palantir.net Moderator: George Demet, Palantir.net, demet@palantir.net

2. Four Key Questions How does PM involvement impact the various phases of a project and the organization…and should it? How should we partner with clients to ensure the project needs are met? What are some ways to mitigate risk, and how do we maintain a stakeholder relationship while saying no to the wrong type of work? What is the difference in managing a Drupal project versus any other technology project?

3. How does PM involvement impact the various phases of a project and the organization... and should it? (Question 1)

4. It is a Good Thing! PM’s are entrusted with managing almost every aspect of project execution—pre- and post- project should be no different. Involvement during transitional periods can often provide more organization and continuity.

5. Project Phases Transition from Sales Project Initiation (Internal) Project Initiation (External) Project Execution Project Transition

6. Transition from Sales Get involved early (but not too early)—contract work isn’t sexy but having input can make or break a project. Improve accountability Gain insight into higher-level strategic objectives Get to know the stakeholder early—who are the players, what do they really care about, how they are measuring success The earlier expectations can be set, the better!

7. Project Initiation (Internal) Oversee internal project initiation to ensure suitable team composition and clear understanding of your own organization’s objectives, constraints, and risks. Identify and socialize risks early. Try and have input into the team composition if you believe that there are quantifiable benefits related to its structure. Ensure that you and internal stakeholders are clear on strategic objectives and budget boundaries.

8. Project Initiation (External) At external project initiation, build mutual understanding and consensus, and set the precedent for partnership in the relationship. Socialize the same risks you brought up internally so there is shared understanding. Ferret out potential pitfalls or issues with regard to the stakeholder-side contact/PM. Establish project boundaries but remain flexible—be a ‘partner’ rather than a dictator. Presenting a well-prepared and organized demeanor starts things off on the right foot!

9. Project Execution PM involvement in all aspects of project execution has positive benefits for the entire team. Get involved in everything from solution definition, design, brainstorming, tasking, reporting, and everything in between. Report, report, report—but make sure reports are meaningful to their recipient stakeholders.

10. Project Transition Use the end of the project to cement your partnership. Developing that relationship is one of the key factors in making additional projects come easily. Ensure the stakeholder is happy; if not, do what is reasonable to rectify the situation. Keep lines of communication open; becoming a partner takes trust and good communication. Sometimes all it takes is a small personal touch: a call to celebrate a win, a small gift to commemorate a launch…these simple, inexpensive touches can make all the difference.

11. How should we partner with clients to ensure the project needs are met? (Question 2)

12. An Effective Partnership Starts With… Understanding the Business Goals Establishing a Shared Vocabulary Ask key questions early that will help guide conversations later Conducting a Full Discovery (if possible)

13. Understanding the Business Goals Truly understanding what stakeholders want requires having sufficient information and interaction. In various projects you will leverage different forms of stakeholder interactions, documentation, and processes.

15. User stories - stakeholder

16. Wires/annotated

17. Designs

18. Wire/designs*

19. Technical specs

20. Requirements

21. Project & sprint plan* In some cases, distinct wireframes are unavailable and annotated designs are used to serve the purpose of wireframes.

23. Stand-up meetings

24. Wiki

25. Tickets

26. Status reports

28. Final Code Release vs Launch

29. Module

30. Block

31. Author

33. Asking RFP/Proposal Questions What level of complexity do you want the site to manage and what level of complexity do you want business process and governance to handle? This helps to start identifying the client’s available resources and balancing that against the budget they have available to use toward automating tasks. How have your sites been managed before? CMS or static HTML? What type of Governance have you had? How will that differ if you move to a CMS? Especially with regard to permissions, roles, moderation, etc.

34. Asking RFP/Proposal Questions How many phases / deliverables of the project will be included in the next statement of work? Strategy / Discover, Wireframes, Designs, Style Guide, Development, QA, Content, Support, etc. How clearly should stakeholder deliverables be documented in an SOW? What are the stakeholder deliverables? Will the stakeholder be providing Wireframes and Designs? Will a Style Guide be provided? Are the expectations / requirements / timelines of stakeholder deliverables documented in the SOW? Internal Question: What type of contract is this? Time & Materials? Fee Cap? Fixed Fee? This answer will impact project management communication and costs. Time & Materials and Fee Cap contracts will require additional project communication/reports.

35. More RFP/Proposal Questions How will a CMS help you achieve your business goals? What is your projected number of users? What is the content proliferation plan? What are the rules around moderation? What workflows should be in place? Who are the team members? What is the site governance plan? Of scope, budget, and timeline, which are the top two priorities?

36. CONDUCTING A FULL DISCOVERY(if possible)

37. Considerations for Discovery Ingredients Additional Techniques for Communicating Requirements Getting what you Need Scheduling Things to Remember

38. Discovery Ingredients Business requirements documents Wireframes Designs Meetings Existing website Third party systems & Integration needs

39. Additional Techniques for Communicating Requirements Combined designs/wireframes Feature inventory with priority Prototyping Test plans (prior to development starting)

41. Knowing what methodology will work best. Scrum, waterfall, both or neither? Agile may not always be best idea from a budgeting stand point but great for quality...

43. Push to complete the discovery prior to providing a final schedule by explaining the risk (missed release dates and going over budget).

45. What are some ways to mitigate risk, and how do we maintain a stakeholder relationship while saying no to the wrong type of work? (Question 3)

47. Portfolio fit

49. Appropriate budget

50. Reasonable timeline

51. Stakeholder preparednessStakeholder/Agency Cultural Fit is also a Risk to Assess

52. The Software Death March Wikipedia says: a death march is a dysphemism for a project that is destined to fail. Usually it is a result of unrealistic or overly optimistic expectations in scheduling, feature scope, or both, and often includes lack of appropriate documentation, or any sort of relevant training. http://en.wikipedia.org/wiki/Death_march_(software_development)

53. Keys to Avoiding a Death March Evaluate key project characteristics and risk at the very beginning, before commitments are made and resources have been used. A project can turn into a “Death March” (misaligned project) at anytime during its lifecycle so it is very important to manage (communicate, escalate and mitigate) risk throughout.

54. VENDOR (DOERS) RISK EVALUATION

57. Portfolio management

58. Industry/audience familiarity

59. Internal processes

61. STAKEHOLDER RISK EVALUATION

65. Stakeholder Preparedness Has the stakeholder been involved in this sort of project before? A savvy stakeholder will have more realistic expectations. If they are new at this, they will require more hand-holding and enforcement of constraints. Not necessarily a deal breaker, but something to recognize and plan for at the outset. Do they have internal resources to support users and/or perform maintenance after project completion? Stakeholder’s internal team(s) may require special documentation and/or training. If there are no internal resources, discuss whether support and/or maintenance needs to be included in the project scope. If so, factor this into your consideration of skillset, resource availability, portfolio fit, and budget.

66. STAKEHOLDER/AGENCY CULTURAL FIT

68. Risk Considerations Resource (Person or System) Downtime & Attrition Other Project Work Quality of Project Outcome Company Reputation Risk Mitigation

69. Resource Downtime & Attrition Temporary or permanent team member or system unavailability can derail a project Don’t kid yourself – systems go down, fail, don’t perform as expected. People get sick (even you!), they go on vacation, and sometimes they move on to other opportunities (to be blunt, they quit). What will you do when that happens?

71. Consider holidays and seasonal effects (eg, flu season, weather-related work outages)

73. Do you have talent you can subcontract to if needed?

75. Quality of Project Outcome How likely is this project to succeed? Review all of the criteria discussed earlier Is the project concept itself of high quality? If known, is the visual design direction good? Are the unknowns under your control? Is the stakeholder savvy enough to understand and fulfill their role in project success? Does the stakeholder understand and accept the project constraints?

77. Beware of projects that are poorly designed, have sloppy information architecture, or are a “step down” from your other work.

79. Question 4: What is the difference in managing a Drupal project versus any other technology project? (Question 4)

80. Special Issues in Drupal Projects Site Governance Issues Special Training Considerations Content Plans Support Issues Dispelling Myths How Using Drupal Affects Design

81. Site Governance Issues Establishing site management processes Setting appropriate roles and permissions Understanding roles and permissions Creating and using editorial workflows Understanding different user experiences

82. Why this Matters Drupal admin can be very powerful, giving business units unprecedented influence over their pages. However, it is not intuitive to new users. Well-planned, designed, and explained site administration is critical to the long-term effectiveness of the site and stakeholder satisfaction.

83. Establishing Site Management Processes The Drupal admin system touches every aspect of a site Complex sites with many admin users have many opportunities for errors It is vital to carefully consider the different types of admin users, how they relate to each other, and what each needs to accomplish

84. Setting Appropriate Roles and Permissions With the wrong permissions, it is entirely possible for admin users to significantly alter—or do worse to—the entire site Users should be granted permissions on an as-needed basis; full admin rights should be heavily restricted Refer to site management processes to identify which user roles require what permissions

86. “That page looks weird”

87. “I don’t have that button”

89. What You Can Do Plan site processes, roles and permissions, and workflows at the beginning of the project Grant only the necessary permissions to each role Use workflows to enforce editorial processes Customize the admin look-and-feel to reduce user confusion Provide admin user training and reference documentation

90. Special Training Considerations Drupal’s learning curve is not only steep for developers, but for admin users too Roles & permissions Nodes vs. blocks vs. pages vs. panels Comment and user-generated content moderation Accessing and using form data WYSIWYG quirks Don’t underestimate the effort that needs to go into training site admins, editors, and other admin users!

92. Do they actually need a full-fledged CMS?

94. Identifying relationshipsEstablishing site lexicon/taxonomies

95. Support Issues Aspects of Drupal will be counter-intuitive to those coming from another platform Help clients re-evaluate their processes and roles Can migration be scripted, or will there be manual entry of legacy content? What training and documentation does internal IT require?

97. Distributions/installation profiles

99. Comprehensive demos

100. Blog posts

101. Buffering estimates/project plans

103. What did you think? Locate this session on the DCC website: http://chicago2011.drupal.org/sessions Click the “Take the Survey” link. Thanks!