Project Management as an Art Form

1. Project Management As an Art FormDrupalCon Chicago 2011Nicole Lind, Treehouse Agency, nlind@treehouseagency.comJoel Sackett, Phase 2 Technology, joel@phase2technology.comAmy O’Malley, Palantir.net, omalley@palantir.netModerator: George Demet, Palantir.net, demet@palantir.net

2. Four Key QuestionsHow 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 PhasesTransition from SalesProject Initiation (Internal)Project Initiation (External)Project ExecutionProject Transition

6. Transition from SalesGet involved early (but not too early)—contract work isn’t sexy but having input can make or break a project. Improve accountabilityGain insight into higher-level strategic objectivesGet to know the stakeholder early—who are the players, what do they really care about, how they are measuring successThe 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 ExecutionPM 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 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.

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 GoalsEstablishing a Shared VocabularyAsk key questions early that will help guide conversations laterConducting 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 GoalsWorkshops and meetings Provide 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

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.

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

23. Stand-up meetings

24. Wiki

25. Tickets

26. Status reports

27. Burn reportsEstablishing a Shared Vocabulary For effective communication between stakeholders and providers, we must (literally) speak the same language!Drupal Core

28. Final Code Release vs Launch

29. Module

30. Block

31. Author

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

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

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

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 RequirementsGetting what you NeedSchedulingThings to Remember

38. Discovery IngredientsBusiness requirements documentsWireframesDesignsMeetingsExisting websiteThird party systems & Integration needs

39. Additional Techniques for Communicating RequirementsCombined designs/wireframesFeature inventory with priorityPrototypingTest plans (prior to development starting)

40. Getting What You NeedRequirements 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:

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

42. 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 projectsPre-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:26Provide 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.

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

44. 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 RememberProduce 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.

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)

46. When is it OK to Say No?Usually when the Risk is too high!Recognizing and avoiding The Software Death MarchCriteria for project and/or vendor selection is not met as outlined:Vendor riskApplicable skills

47. Portfolio fit

48. Resource availabilityStakeholder RiskExpectation for cheap, fast, or good

49. Appropriate budget

50. Reasonable timeline

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

52. The Software Death MarchWikipedia 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 MarchEvaluate 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

55. Applicable SkillsWhat skills does the project require?Do you and your team have them?If not:Can your team reasonably learn missing skills for the project?

56. Can you partner or sub these portions?Portfolio FitDoes this project make sense in the context of your prior work and agency evolution?Market positioning

57. Portfolio management

58. Industry/audience familiarity

59. Internal processes

60. BudgetResource AvailabilityDo 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?

61. STAKEHOLDER RISK EVALUATION

62. Cheap, Fast, or Good?You can get it cheap and fast, but it won’t be goodRISK! 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 timeBudget 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 youThe 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 BudgetDoes 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.

63. Reasonable TimelineDoes 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.

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

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

66. STAKEHOLDER/AGENCY CULTURAL FIT

67. Stakeholder/Agency Cultural FitNot everyone can work well togetherEspecially important when working with their internal teamsDo 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 FitCan 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

68. Risk ConsiderationsResource (Person or System) Downtime & AttritionOther Project WorkQuality of Project OutcomeCompany ReputationRisk Mitigation

69. Resource Downtime & AttritionTemporary or permanent team member or system unavailability can derail a projectDon’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?

70. Resource Downtime & AttritionPlan for downtimeBuild it into the project time estimates

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

72. Don’t forget your own potential interruptionsHave a contingency planCan another team member jump in if necessary?

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

74. Can another solution be considered? A work-around? A hack?Other Project WorkThere are tradeoffs…taking on one project means saying no to anotherIf 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?

75. Quality of Project OutcomeHow likely is this project to succeed?Review all of the criteria discussed earlierIs 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?

76. Company ReputationIf the project is successful, will it add to or detract from your reputation?Some projects, even if successful, may negatively affect your reputation.

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

78. 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 MitigationClassify 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.

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

80. Special Issues in Drupal ProjectsSite Governance IssuesSpecial Training ConsiderationsContent PlansSupport IssuesDispelling MythsHow Using Drupal Affects Design

81. Site Governance IssuesEstablishing site management processesSetting appropriate roles and permissionsUnderstanding roles and permissionsCreating and using editorial workflowsUnderstanding different user experiences

82. Why this MattersDrupal 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 ProcessesThe Drupal admin system touches every aspect of a siteComplex sites with many admin users have many opportunities for errorsIt 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 PermissionsWith the wrong permissions, it is entirely possible for admin users to significantly alter—or do worse to—the entire siteUsers should be granted permissions on an as-needed basis; full admin rights should be heavily restrictedRefer to site management processes to identify which user roles require what permissions

85. Understanding Roles and PermissionsWhat permissions does each role have?Especially important for editors and managers to understand who has what publishing and layout-altering rightsHow do these roles relate to each other?Do each role’s permissions affect its associated users’ experiences?“I don’t see that [post/page]”

86. “That page looks weird”

87. “I don’t have that button”

88. “Why can’t I change that [block/page/menu]?”Creating and Using Editorial WorkflowsEnforce editorial control over contributorsCreate a review and approval process based on contributor rolesThink about if/how editors should be notified of pending content, and contributors notified of rejection or approvalDrupal editorial workflow is not always intuitive to new usersEnsure 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 ExperiencesHistorically, differentiation between admin and visitor portions of site has not been strongConfusion can result in time spent chasing non-existent bugs, frustration in attempting site edits, and panic over content visitors cannot actually see

89. What You Can DoPlan site processes, roles and permissions, and workflows at the beginning of the projectGrant only the necessary permissions to each roleUse workflows to enforce editorial processesCustomize the admin look-and-feel to reduce user confusionProvide admin user training and reference documentation

90. Special Training ConsiderationsDrupal’s learning curve is not only steep for developers, but for admin users tooRoles & permissionsNodes vs. blocks vs. pages vs. panelsComment and user-generated content moderationAccessing and using form dataWYSIWYG quirksDon’t underestimate the effort that needs to go into trainingsite admins, editors, and other admin users!

91. Content PlansIs Drupal the right answer?What does their content look like? If it is mostly static, is Drupal overkill?

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

93. Why did they choose Drupal?How does legacy content translate?Reframing “pages” into “nodes”

94. Identifying relationshipsEstablishing site lexicon/taxonomies

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

96. Dispelling MythsSometimes 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 meanBase install

97. Distributions/installation profiles

98. Custom solutionsDispelling MythsHow to mitigate?Prototyping

99. Comprehensive demos

100. Blog posts

101. Buffering estimates/project plans

102. Managing the WIBCI effect (wouldn’t it be cool if...)How Using Drupal Affects DesignIterative development can affect stakeholder mindset.Consider iterative designPlan accordingly – you might need to stretch another phase to account for design running longer.

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

Project Management as an Art Form

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Project Management as an Art Form (20)

More from Treehouse Agency (11)

Recently uploaded (20)

Project Management as an Art Form

Editor's Notes