I'm Leaving You: The Risks of Dumping Your Old CMS for Drupal and How to Manage Them
Download as KEY, PDF2 likes3,040 views
The document discusses the challenges and risks associated with migrating to Drupal CMS, emphasizing the importance of managing expectations and understanding team dynamics during the transition. It identifies common misconceptions, outlines potential risks, and suggests strategies for risk assessment and mitigation to facilitate a smoother migration experience. Key takeaways include the necessity of clear communication, setting realistic goals, and being sensitive to team members' reactions to change.
More Related Content
Similar to I'm Leaving You: The Risks of Dumping Your Old CMS for Drupal and How to Manage Them (20)
I'm Leaving You: The Risks of Dumping Your Old CMS for Drupal and How to Manage Them
- 2. Business and Strategy I’m Leaving You: The Risks of Dumping Your Old CMS for Drupal and How to Manage Them Presented by Nicole Lind Group Vice President, [email protected]
- 3. Why this session? Surprise dangers lurk! Unrealistic expectations Drains on resources Difficulty with change Unrecognized risks
- 4. The goals Set better expectations Provide a risk assessment framework Minimize surprises Bring sanity to a potentially stressful experience
- 6. Doublespeak is language that deliberately disguises, distorts, or reverses the meaning of words. Doublespeak may take the form of euphemisms (e.g., “downsizing” for layoffs), making the truth less unpleasant. From Wikipedia (paraphrased)
- 7. Understanding Implication: Drupal Doublespeak Your site is practically already built! “There’s a Truth: Module for That!” You’re going to need plenty of development work to get the custom look and functionality you have in mind.
- 8. Understanding Implication: Drupal Doublespeak “Of course the designs are final”. Just a few tweaks are “Final designs” expected and shouldn’t impact functionality. Truth: Even small design changes can introduce significantly new functionality.
- 9. Understanding Implication: Drupal Doublespeak The new CMS will be completely customized, but “Flexibility” should act like shrink wrapped software with documented manuals and no bugs. Truth: Your Drupal CMS is often custom-made. It will require a debugging period and custom documentation.
- 10. Understanding Implication: Drupal Doublespeak Drupal is free! Of course it’s going to be cheaper! “Cost Savings” Truth: Every project is unique. While Drupal is free, the development, support, and hosting of your project is not. Savings (and costs) will vary.
- 11. Understanding Implication: Drupal Doublespeak There are Drupal developers everywhere! “There’s talent all Truth: over the world” Hiring and maintaining Drupal talent is getting harder and harder no matter where your organization operates
- 13. Tribalism is a strong Cultural or ethnic identity that separates one member of a group from the other members of another group. From Wikipedia (paraphrased)
- 14. Understanding the Evangelist Drupal Tribe Passive-aggressive Members Common tribe Openly hostile members of a Know-it-all Drupal CMS Apathetic migration Protector Chief
- 15. Evangelist
- 16. Evangelist Description Brought Drupal to the organization or pushed for a major over hall of the existing implementation Caveats Depending on how they “sold” Drupal (which is often an oversell with Drupal Speak terms) to the organization will determine how to handle the rest of the tribe members. What to do with them Manage expectations and bring everyone back to reality
- 18. Passive- Description Expresses aggression in non- Aggressive assertive (i.e. indirect) ways Caveats Although not a very vocal tribe member, the passive aggressive often uses subversive emails and conversations to pass blame and avoid doing their job What to do with them Point out the inconsistency between their words and actions
- 19. Openly Hostile
- 20. Openly Hostile Description Openly antagonistic to the project. They will be the first person to say I told you Drupal was a bad idea Caveats Often motivated by fear and they often feel they should be leading the project effort What to do with them Assign an important job in the project to this person or completely eliminate them. There is no sitting on the fence or shades of grey
- 21. Know-It-All
- 22. Know-it-All Description Often a very experienced technical person but they are new to Drupal. Caveats Confusion drives this person and they will complain about the inadequacies of Drupal but not really know Drupal What to do with them Train these people as soon and as much as possible!
- 23. Apathetic
- 24. Apathetic Description The apathetic will sit on the sideline and make no meaningful contribution to the project Caveats Usually much of the editorial staff is apathetic and unfortunately they don’t say much about the CMS until the new product is already built What to do with them Preview as much of the early build through demos and test accounts
- 25. The Protector
- 26. The Protector Description Keeper of the budget and sustains the migration effort through resourcing Caveats Sometimes unclear who this member is and how much power they have What to do with them Make this tribe member your friend. Take them for dinner and drinks. Schmoozing!
- 27. The Chief
- 28. The Chief Description The mover off all things related to the migration effort. Understands the strategy, language and players associated with getting the job done Caveats Not always well liked and may need to be hard on other tribe members What to do with them Empower this tribe member with real authority
- 29. Understanding Change in the Drupal Tribal Community Key Considerations
- 30. People are scared. Tough changes can make people redundant, threaten jobs and require the restructuring of the organization
- 31. Speed of change matters. Slow is usually easier, but many web projects require urgency and speed to market
- 32. People react differently. Some are more impacted by change and sometimes do not cope well; may act out, taking on tribe roles of the openly hostile or passive aggressive member.
- 33. Change is inherently risky. It should be managed with care and professionalism
- 34. Migrating is Inherently Risky and What To Do Evolving People and Language Through Risk Assessment
- 35. Identifying the most common risks Risks Potential Impacts No Drupal experience Cost Unknown dependencies Schedule Scheduling Performance Double data entry Unidentified block behavior Old legacy system has no clear migration path Lack of clear content mapping
- 36. Survey users and stakeholders for additional potential risk ✦ Don’t forget members of the technical team (including developers, system administrators and hosting partners). ✦ Take time to understand editor and content contributor processes and expectations for the admin.
- 37. Setting up a risk tracking method Many formats available on the web; Google “risk analysis” or “risk assessment” for ideas. Most often includes tracking risk for Likelihood of occurring and Impact on the project; impact could be financial, timeline, or quality of the outcome
- 38. Likelihood definitions Likelihood description Percentage of possibility Almost certain > 95% Likely 65% to 95% Possible 35% to 65% Unlikely 5% to 35% Rare < 5%
- 39. Impact definitions Impact Description Very serious An event whose occurrence will impact the project’s cost, schedule or feature set so severely that the project will be terminated. Serious An event that seriously impacts (more than 10%) project budget, feature set and/or schedule; alternately denotes serious loss in required functionality that will be unacceptable to business stakeholders. Moderate An event that, if it occurs, will cause a modest change to the project’s technical architecture, a modest loss of some non-critical functionality, and/or a modest loss of some non-critical operational performance requirements. Minimum acceptable requirements will be achieved. Budget and/or schedule loss will be less than 10%. Minor An event that, if it occurs, will cause small cost (and/or schedule) increases that, in most cases, can be absorbed by the project. Little to no loss of required functionality.
- 40. Sample risk assessment Risk Likelihood Impact Unnecessary project hours (budget) Likely Minor spent waiting for stakeholder approvals Emerging requirements after Likely Moderate discovery completed which could impact timeline, budget and quality Hosting solution is not “approved” as Almost certain Very Serious of yet No clear migration path of existing Almost certain Serious content from old CMS which puts timeline at significant risk
- 41. Creating risk mitigation plans for Drupal
- 42. Common sense plans that help reduce risk Set clear and measurable goals Conduct a project discovery Provide as much training and documentation as budget and schedule allows
- 43. Setting clear and measurable goals “We are moving “We expect to “One of the main to Drupal save a lot of goals of this because we want money moving project is to our CMS to be to Drupal.” double our more flexible.” traffic the first month after launch.”
- 44. Setting clear and measurable goals Unclear “We are moving “We expect to “One of the main to Drupal save a lot of goals of this because we want money moving project is to our CMS to be to Drupal.” double our more flexible.” traffic the first month after launch.”
- 45. Setting clear and measurable goals Unclear Not Specific “We are moving “We expect to “One of the main to Drupal save a lot of goals of this because we want money moving project is to our CMS to be to Drupal.” double our more flexible.” traffic the first month after launch.”
- 46. Setting clear and measurable goals Unclear Not Specific Unrealistic “We are moving “We expect to “One of the main to Drupal save a lot of goals of this because we want money moving project is to our CMS to be to Drupal.” double our more flexible.” traffic the first month after launch.”
- 47. Setting clear and measurable goals Goals need to be specific and realistic to help set expectations for success of the project. Goals also focus our attention on higher priority activities versus lower priority activities.
- 48. Project discovery… Helps stakeholders and implementation teams to understand the real needs of the migration project Is ideal for fleshing out the unknowns (risk) of a project. Can be as short or long as needed, but should be done regardless
- 49. Training & Documentation Budgets and timelines generally don’t cover the real outlay for training and documentation…which is a risk.
- 50. More efficient delivery Create inline documentation as much as possible. Saves time and money relative to creating documentation in two places. Regularly demo functionality for stakeholders. These sessions can be recorded and used for future training and documentation needs. Maintain a central repository for all project documents.
- 51. Putting everything together Risk Likelihood Impact Mitigate Plan Unnecessary project hours Likely Minor No (budget) spent waiting for stakeholder approvals Emerging requirements after Likely Moderate Yes Implement ticketing system that discovery completed which could tracks changes to features. System should be able to impact timeline, budget and identifying bugs from quality improvement request Hosting solution is not Almost Very Yes Push launch timeline out 3 weeks “approved” as of yet to account for delay. certain Serious Communicate to all project stakeholders No clear migration path of Almost Serious Yes Start looking for outside vendors existing content from old CMS that specialize in data migration certain which puts timeline at significant risk
- 52. Distributing and publishing the risk and mitigation plans ✦ Initial risk assessments should be placed in the project discovery documentation (if one is conducted) ✦ On-going risk assessments should be shared with project stakeholders through meetings, email, scrums, etc. ✦ Once new risk are communicated the document should be updated and saved to the central document repository (i.e. Google docs, Basecamp, etc.)
- 53. Final thoughts ✦ Be patient ✦ Understand the people and language of the community moving to Drupal ✦ Be sensitive to how other tribal members deal with change
- 54. #1 Key Takeaway Identifying and managing risk is the most effective way to evolve your community and successfully migrate to Drupal
- 55. 52 Thank You Questions Questions?
- 56. What did you think? Locate this session on the DrupalCon Denver website http://denver2012.drupal.org/program Click the “Take the Survey” link. Thank You!
Editor's Notes
- #2: \n
- #3: \n
- #4: \n
- #5: \n
- #6: \n
- #7: \n
- #8: \n
- #9: \n
- #10: \n
- #11: \n
- #12: \n
- #13: \n
- #14: \n
- #15: \n
- #16: \n
- #17: \n
- #18: \n
- #19: \n
- #20: \n
- #21: \n
- #22: \n
- #23: \n
- #24: \n
- #25: \n
- #26: \n
- #27: \n
- #28: \n
- #29: \n
- #30: \n
- #31: \n
- #32: \n
- #33: \n
- #34: \n
- #35: \n
- #36: \n
- #37: Hosting is often overlooked in budgets and requires critical skills that maybe missing.\n\nOften a very overlooked area for risk.\n
- #38: \n
- #39: \n
- #40: \n
- #41: \n
- #42: \n
- #43: \n
- #44: \n
- #45: \n
- #46: \n
- #47: \n
- #48: Once something is known, it often dramatically reduces the risk and exposure involved in migrating to Drupal\n
- #49: \n
- #50: \n
- #51: \n
- #52: \n
- #53: \n
- #54: \n
- #55: \n
- #56: \n