Project Management As an Art FormDrupalCon Chicago 2011Nicole 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

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?

How does PM involvement impact the various phases of a project and the organization...

and should it?(Question 1)

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.

Project Phases

• Transition from Sales

• Project Initiation (Internal)

• Project Initiation (External)

• Project Execution

• Project Transition

Transition from SalesGet 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!

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.

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!

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.

Project TransitionUse 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.

How should we partner with clients to ensure the project

needs are met?(Question 2)

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)

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.

Understanding the Business Goals

Workshops and meetingsProvide your face time with stakeholders and that will allow you to understand personalities, culture, and unwritten priorities.

Documentation formatsProvide 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.

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

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

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.

Asking RFP/Proposal QuestionsWhat 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.

Asking RFP/Proposal QuestionsHow 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.

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?

CONDUCTING A FULL DISCOVERY(if possible)

Considerations for Discovery

• Ingredients

• Additional Techniques for Communicating Requirements

• Getting what you Need

• Scheduling

• Things to Remember

Discovery Ingredients

• Business requirements documents

• Wireframes

• Designs

• Meetings

• Existing website

• Third party systems & Integration needs

Additional Techniques for Communicating Requirements

• Combined designs/wireframes

• Feature inventory with priority

• Prototyping

• Test plans (prior to development starting)

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

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.

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.

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)

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

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)

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.

VENDOR (DOERS) RISK EVALUATION

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?

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

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?

STAKEHOLDER RISK EVALUATION

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.

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.

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?

Stakeholder PreparednessDoes 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.

Stakeholder PreparednessHas 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.

STAKEHOLDER/AGENCY CULTURAL FIT

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.

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.

RISK EVALUATION

Risk Considerations

• Resource (Person or System) Downtime & Attrition

• Other Project Work

• Quality of Project Outcome

• Company Reputation

• Risk Mitigation

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?

Resource Downtime & AttritionPlan 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?

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?

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?

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!

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.

Question 4: What is the difference in managing a Drupal

project versus any other technology project?

(Question 4)

Special Issues in Drupal Projects

• Site Governance Issues

• Special Training Considerations

• Content Plans

• Support Issues

• Dispelling Myths

• How Using Drupal Affects Design

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

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.

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

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

Understanding Roles and PermissionsWhat 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]?”

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?”

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

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

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!

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

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?

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

Dispelling Myths

How to mitigate? Prototyping Comprehensive demos Blog posts Buffering estimates/project plans Managing the WIBCI effect (wouldn’t it be cool

if...)

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.

What did you think?Locate this session on the DCC website:http://chicago2011.drupal.org/sessions

Click the “Take the Survey” link.

Thanks!