Drupal project management

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.

14. Understanding the Business Goals
Workshops and meetings
Provide your face time with stakeholders and that will allow you to
understand personalities, culture, and unwritten priorities.
Documentation formats
Provide the hard information and known requirements. Some are
created by stakeholders and others by vendors (the doers).
•RFP
•User stories - stakeholder
•Wires/annotated
•Designs
•Wire/designs*
•Technical specs
•Requirements
•Project & sprint plan
* In some cases, distinct wireframes are unavailable and
annotated designs are used to serve the purpose of
wireframes.

15. Understanding the Business Goals
"Final" scope documentation
Provides the firm, agreed-upon requirements and
processes of the project and serves as the basis for
execution. May take many formats (see Documentation
formats).
Iterative project communications
Keeps you on track and in touch throughout the project.
•Basecamp
•Stand-up meetings
•Wiki
•Tickets
•Status reports
•Burn reports

16. Establishing a Shared Vocabulary
For effective
communication
between
stakeholders and
providers, we must
(literally) speak the
same language!
• Drupal Core
• Final Code Release vs
Launch
• Module
• Block
• Author
• Moderation

17. Asking RFP/Proposal Questions
What is the priority level for each of these items with regard to this
project: Budget, timeline, scope?
This prioritization helps us to guide the discussions in the early
project conversations. For example, if there is a specific date that is
key for the project, then timeline should be high priority.
How many weeks do you want scheduled for your site review and
user acceptance testing (UAT) time period?
Once the Development Phase is complete, there will be a UAT time
period for you to review the site and to open tickets. How many
weeks do you want scheduled for this?
This will help the stakeholder begin to identify the resources that
they have and will need in order to fulfill their responsibilities after
development.

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

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

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

21. CONDUCTING A FULL DISCOVERY
(if possible)

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

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

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

25. Getting What You Need
Requirements means different things to different people. Have a
clear picture or standard set of requirements deliverables you
expect and guide the stakeholder towards a shared end goal.
• Never produce something ‘just because we always have.’
• Determine how you can effectively work with different stakeholder types
during discovery which means:
 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...
 Be mindful that you may have to bridge the gap between an 'old
school' (controlled and inflexible) IT team, and the more fluid aspects
of development often used on Drupal projects

26. Pre-Scheduling
Sometimes stakeholders want and need to know how long the
project will take prior to the requirements being fully
understood. What can be done:
26
• Provide a “finger in the air” and guesstimate. When
providing this type of early scheduling it is best to
avoid doing so in a fixed bid project.
• Push to complete the discovery prior to providing a
final schedule by explaining the risk (missed release
dates and going over budget).
• Provide an estimated high level project plan based
on the initially identified budget or estimates. If the
scope increases, the timeline does as well.

27. Things to Remember
• Produce methodology-agnostic deliverables.
• Use the right tool for the job.
• Collaborate - responsibility doesn’t have to be
JUST the stakeholder or JUST your team!
• Be careful of criticizing existing deliverables
produced by others—focus on constructive
criticism.

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

29. When is it OK to Say No?
• Usually when the Risk is too high!
– Recognizing and avoiding The Software Death March
– Criteria for project and/or vendor selection is not met as
outlined:
Vendor risk
• Applicable skills
• Portfolio fit
• Resource availability
Stakeholder Risk
• Expectation for cheap, fast, or
good
• Appropriate budget
• Reasonable timeline
• Stakeholder preparedness
Stakeholder/Agency Cultural Fit is also a Risk to Assess

30. 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_(softwar
e_development)

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

32. VENDOR (DOERS) RISK EVALUATION

33. Applicable Skills
• What skills does the project require?
• Do you and your team have them?
• If not:
 Can your team reasonably learn missing skills for
the project?
 Can you partner or sub these portions?

34. Portfolio Fit
Does this project make sense in the context of
your prior work and agency evolution?
 Market positioning
 Portfolio management
 Industry/audience familiarity
 Internal processes
 Budget

35. Resource Availability
• Do you have enough people, with the right
mix of skills, to execute this project?
 If not, can you partner or sub?
• If the project is going to max out your
resources, is it worth the risk of rejecting new
work during the project period?
• Will another project be derailed if this one
overruns its intended launch date?

36. STAKEHOLDER RISK EVALUATION

37. Cheap, Fast, or Good?
You can get it cheap and fast, but it won’t be good
 RISK! If they want this, walk away! Poorly planned and executed projects will
do nothing for your professional reputation, and chances are good they will
still be dissatisfied with the outcome.
You can get it (sort of) cheap and good, but it will take a long time
 Budget clients may be worthwhile if a slow and steady approach of well-
defined, incremental or phased work it taken.
You can get it fast and good, but it will cost you
 The most common legitimate scenario in enterprise projects. High
expectations are to be expected, but be careful that scope creep and
subcontracting costs don’t eat up all your profits. Make sure that the project
and its constraints are fully understood at the outset as there will be little
room for error and re-working.

38. Appropriate Budget
• Does it fit your business model?
• Is it realistic to the project scope?
• Can you make a profit?
• Are they looking for a bargain?
RED FLAG! Bargain-hunters tend to be very demanding
and prone to excessive scope creep, cutting corners,
and placing blame.

39. Reasonable Timeline
Does the timeline allow for proper planning,
development, and testing of the project?
 “Just barely” means “no.” It’s human nature to
underestimate how much time projects really
need.
 If not, is the stakeholder willing to modify the
scope, prioritize the feature set into phases, or
increase the budget to bring in additional
resources?

40. Stakeholder Preparedness
Does the stakeholder know what they want?
Simple question? Not really. If they don’t know *why* they are doing the
project, it will be difficult to build the right solution and control scope
creep.
How much discovery and specification development has already occurred?
Make sure to allocate enough time and budget to do a proper discovery
and get everyone on the same page.
RISK! If they have inadequate discovery, but insist on building right
away, walk away. It will be nearly impossible to keep this project on
track and build something they will be satisfied with.

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

42. STAKEHOLDER/AGENCY CULTURAL FIT

43. Stakeholder/Agency Cultural Fit
• Not everyone can work well together
• Especially important when working with their
internal teams
• Do communication styles mesh?
 RISK! Communication will be critical to the
success of the project. Identify and address any
problems in this area right away.

44. Stakeholder/Agency Cultural Fit
• Can project management approaches be adapted to fit
client’s internal processes and priorities?
• Are expectations and priorities aligned, or at least open to
reasonable concessions when necessary?
 RISK! If you cannot achieve alignment in project priorities, you
run a very high risk of scope creep, team frustration, and
severe stakeholder dissatisfaction.
• Do you like each other?
 RISK! Hostility at the outset is a very, very bad sign. It will only
get worse as the project progresses.

45. RISK EVALUATION

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

47. 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?

48. Resource Downtime & Attrition
Plan for downtime
 Build it into the project time estimates
 Consider holidays and seasonal effects (eg, flu season,
weather-related work outages)
 Don’t forget your own potential interruptions
Have a contingency plan
 Can another team member jump in if necessary?
 Do you have talent you can subcontract to if needed?
 Can another solution be considered? A work-around? A hack?

49. Other Project Work
• There are tradeoffs…taking on one project means saying no to another
• If your resources will be fully booked, is this project good enough to turn down
another?
• Will this project overextend your resources and put another project at risk of
failure?
• How does this project compare to other potential projects you are in the running
for? If there is a better one, how likely is it to come through, and are you willing to
take the gamble?
• If you turn down this project, and the other fails to come through, will you, as a
company, be okay?
• Which projects are going to be the most profitable and contribute the most to
your reputation? Are you properly allocating resources to, and protecting the
integrity of, these projects?

50. 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?

51. Company Reputation
• If the project is successful, will it add to or detract from your
reputation?
 Some projects, even if successful, may negatively affect your
reputation.
 Beware of projects that are poorly designed, have sloppy information
architecture, or are a “step down” from your other work.
 Try to get a sense of the client’s internal management and processes;
poor use and maintenance of your project can eventually reflect badly
on you.
• How likely is project success?
• How does the stakeholder talk about past and present vendors?
 Indicative of how they will talk about you!

52. Risk Mitigation
• Classify the type of risk (quality, monetary or scheduling).
• Conduct a risk assessment – Discover the things that can go
wrong by uncovering as many uncertainties and gaps in the
project.
• Analyze each risk in terms of impact and likelihood of occurring
(various rating scales can be used).
• Mitigation plans should be developed for risk items that are
rated as mostly likely to occur and have the most catastrophic
impact on the project.

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

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

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

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

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

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

59. Understanding Roles and
Permissions
What permissions does each role have?
 Especially important for editors and managers to understand
who has what publishing and layout-altering rights
How do these roles relate to each other?
Do each role’s permissions affect its associated users’
experiences?
 “I don’t see that [post/page]”
 “That page looks weird”
 “I don’t have that button”
 “Why can’t I change that [block/page/menu]?”

60. Creating and Using Editorial
Workflows
• Enforce editorial control over contributors
• Create a review and approval process based on contributor
roles
• Think about if/how editors should be notified of pending
content, and contributors notified of rejection or approval
• Drupal editorial workflow is not always intuitive to new users
• Ensure that both editors and contributors understand the
workflow and what happens when they “publish” their content.
 “I published a post, why can’t anyone else see it?”

61. Understanding Different User
Experiences
• Historically, differentiation between admin
and visitor portions of site has not been
strong
• Confusion can result in time spent chasing
non-existent bugs, frustration in attempting
site edits, and panic over content visitors
cannot actually see

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

63. 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!

64. Content Plans
Is Drupal the right answer?
 What does their content look like? If it is mostly static, is
Drupal overkill?
 Do they actually need a full-fledged CMS?
 Why did they choose Drupal?
How does legacy content translate?
 Reframing “pages” into “nodes”
 Identifying relationships
Establishing site lexicon/taxonomies

65. 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?

66. Dispelling Myths
• Sometimes when someone hears about Drupal, its
modules and community, unfair assumptions are
made.
• Dispelling the myth of the “Whatever Module”
• What does “out of the box” really mean
 Base install
 Distributions/installation profiles
 Custom solutions

67. Dispelling Myths
How to mitigate?
 Prototyping
 Comprehensive demos
 Blog posts
 Buffering estimates/project plans
 Managing the WIBCI effect (wouldn’t it be cool
if...)

68. How Using Drupal Affects
Design
• Iterative development can affect
stakeholder mindset.
• Consider iterative design
• Plan accordingly – you might need to
stretch another phase to account for
design running longer.

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