Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Scoping and Estimating WordPress Projects as an Agency


Published on

WordCamp LAX 2016 presentation by John Giaconia and Kara Hansen. #WCLAX

Published in: Software
  • Login to see the comments

Scoping and Estimating WordPress Projects as an Agency

  2. 2. AGENDA • Who we are • Understanding and controlling scope • Estimating and tracking time • Managing customer expectations • Continuous improvement
  3. 3. WHO WE ARE Disney’s Digital Media Agency helps Disney business units build, operate and enhance digital media properties from concept through launch and operations. We have launched dozens of WordPress sites for internal customers across Disney businesses. Since October 2015 we’ve prepared more than 90 project estimates. Many of us have agency/consulting backgrounds.
  5. 5. KNOW WHAT YOU ARE DOING BEFORE YOU START DOING IT “You can use an eraser on the drafting table or a sledge hammer on the construction site.” - Frank Lloyd Wright A solid discovery process is key to a successful project.
  6. 6. KEY GOALS FOR DISCOVERY • Why are we doing this? • What is the goal? What problem are we solving? • What are we doing? • Universally understood and agreed upon scope • What’s the budget? • Scope must be clear in order to communicate accurate budget requirements • Do these line up? • Ensure alignment between customer's wish list, budget, timeline, and any other constraints
  7. 7. KNOW THE CRITICAL CONSTRAINTS • What is your timeline? • Is there a specific date you need this to be live? • If date is aggressive, can we start with a scaled-down initial version? • What is your budget? • Get an objective number • Don’t think with your own wallet – “cheap” and “expensive” are relative and subjective • What level of quality do you need? • Minimum Viable Product (MVP) rough cut vs. a fully featured and polished initial release
  8. 8. MEASURE AND QUANTIFY Adjectives are subjective and relative. Keep asking questions until you and the customer agree on an objective measure or description of words like these. • Fast • Clean • Modern • Elegant • Beautiful • Professional • Sophisticated • Sleek
  9. 9. DON'T FORGET OVERHEAD Overhead: Non-technical work needed to support project operations • Contract, insurance, billing/invoicing/taxes, customer relations, demos/walkthroughs, status calls/reporting, accounts/access/onboarding • Ensure you account for this time - it's part of your costs • Build into the rate or call out as line items in your bid • Do not underestimate the paperwork burden, especially with large companies
  10. 10. THE PROJECT TRIANGLE Pick two. You can't have them all. CHEAP takes longer minimal scope costs more impossible
  11. 11. EXAMPLE SCOPE CHECKLIST • Critical constraints (budget, timeline, scope/quality, etc.) • Who is the audience? • Authentication? (e.g. Facebook/Google login) • Example sites that provide an experience the customer likes? • What does the customer already have? • Designs? Hosting? Domain? Existing source code? • What other systems does it interface with? • What is the content and how is it published? • Custom publishing needs? (e.g. workflow, roles) • Media, Microsoft Office documents, PDFs • Additional languages • Be aware of data handling • Domestic PII, International PII, PCI, file uploads
  12. 12. ARE YOU THE RIGHT PARTNER? • Is WordPress a clear fit for the project needs? • Know what WordPress is designed for and its strengths; be thoughtful when considering a project that pushes WordPress outside its strengths • Does your team have the resources/skills set to deliver this project? • Number of resources (volume of work) • Type of resources (type of skills) • Be candid about availability and scheduling constraints • Can you partner with someone?
  14. 14. BREAK IT DOWN Why break down work into discrete tasks? • Limiting the field of options • What is a 4 hour task vs an 8 hour task? Probably easy • What is a 6 hour task vs a 7 hour task? Probably hard, so why use it? • If it is more than a day, break it down • Easier to assess • Reduce risk • Less risk of major estimate gaps when individually estimating a breakdown of tasks, as opposed to one large overall scope • Being inaccurate on a single task by a huge margin is smaller impact if each individual task is smaller
  15. 15. GRANULAR TASK ESTIMATION Days, hours, story points – the method is less important than using a consistent approach • Breaking scope into tasks is essential to truly understanding level of effort (LOE) • Capture assumptions • Role-by-role estimates; use a percentage formula for QA • 10% - 30% depending on development complexity and target level of testing rigor
  16. 16. Hours Human Construct .25 I can do that right now .50 I can do that quickly 1.00 It'll take an hour 2.00 It'll take a couple hours 4.00 It'll take half a day 8.00 It'll take a day 12.00 It'll take a day and a half 16.00 It'll take a couple days 20.00 ...half of a week... 24.00 ...3 days... 32.00 ...4 days... 40.00 ...a week... 60.00 ...a week and a half... 80.00 ...two weeks... Is this actually part of a larger task? Typical task sizes Can this be broken down into more granular tasks? ESTIMATE VALUES CHART
  17. 17. PROJECT MANAGEMENT AND OVERHEAD • Ramp-up time • How much setup time is required before you can begin work on deliverables? • Administrative tasks • Daily tracking, velocity, pace, burn down charts • Use a tool for task tracking (JIRA, Basecamp, etc.) • Use source control (e.g. GitHub) • Frequency and level of detail in reporting • What format and frequency of reporting does the customer want? • How much time per day or week is needed to prepare and present that?
  18. 18. QUANTIFYING WORDPRESS DEVELOPMENT WordPress Entity Architecture Construct Custom Post Types Data modeling Custom Taxonomies Data organization Secondary templates Data presentation Design Revisions Data experience Search Facets Data indexing Content Entry Data ingest Interfaces Data transport Can you determine how many of the following you will need to create?
  20. 20. MUTUAL AGREEMENT Alignment with the customer on what you are doing and to what extent you are doing it is critical. Otherwise, you can't meet the customer’s expectations.
  21. 21. DELIVERABLES: BE SPECIFIC • Don’t: “Custom design” • This means it's done when the customer decides it's done, regardless of hours, iterations, or your costs • Do: “Custom design including 2 initial concepts and 3 rounds (up to 8 hours each) of revisions to the selected concept” • Specific, measurable, objective, time boundaries
  22. 22. YOU NEED A CONTRACT A mutually executed contract specifying the work to be completed is essential - it’s the project governance of record. Milestone/deliverable vs. time and materials - which is appropriate for your project? • Milestone: specific scope of work, timeline, and budget • More waterfall • T&M: scope in flux, timeline flexible, customer looking to iterate and try out different ideas • More agile
  23. 23. HOW LONG? In order to accurately estimate project duration, consider factors beyond the design and development hours. • Scheduled calendar events: vacation, holidays • Allow for the unexpected: pad a bit for sick days, etc. • Are your team members full time? • If someone supports you only 8 hr/wk, account for that • If someone is full time but 50-50 across 2 projects, account for that • What approvals will the customer require? • If the CEO needs to approve designs, it might take 2+ weeks to get on their schedule
  24. 24. ASSUMPTIONS AND EXCLUSIONS Document these for clarity and to ensure nothing gets missed by either side. • Example Assumptions • Vendor assumes Customer will perform all content entry once the site is built • Vendor assumes Customer will provide all photos, logos, and other assets • Example Exclusions • Vendor will not perform translation services; if content must be presented in multiple languages, Customer must translate it • Search Engine Marketing (SEM) services not included
  25. 25. SCOPE CHANGE AND CREEP • "Yes, if" - New scope can sometimes be accommodated • Either it replaces something else, or • The timeline or budget increases • Track and document these items • If accommodating: document in a change order • If deferring: move to a Future Phase backlog • Flexibility is limited • If work on a 100-hour task has started, it can't be removed and replaced with a different 100-hour task • (Don’t) Do them a solid • Customers tend to notice things that didn’t get completed more than extras you throw in
  26. 26. COMMUNICATE THEN, COMMUNICATE • Establish a process for communicating progress/status, and do so consistently • Be as detailed and transparent as you can about what will be done when • Be honest if you hit a challenge • The customer is going to find out anyway • Not being forthright destroys relationships • Actively listen • Pay attention to customer needs, preferences, pet peeves/language • Adjust to accommodate whenever possible • Don't disappear • Dropping out of communication freaks customers out
  27. 27. BE A PARTNER • Be honest with your customers • Use your expertise to guide them • Call out outlier feature requests • Sure, we can do that - but it will cost a lot for little value • Be invested in their success • If they are successful, you are successful
  29. 29. WHY RETROSPECTIVES? These are invaluable opportunities to review what worked and didn't work, and understand how you can do better. • If you tracked your time against tasks, use that data to refine and improve estimating • Ask your customers for feedback - people like to give feedback, and you should like getting it • In person is ideal, but take feedback however you can get it (email, phone call, online survey, etc.) • Every piece of feedback, positive or constructive, is an opportunity
  30. 30. WHAT TO ASK The basics: • What went well? • What didn’t go so well? • What made this project different from others? • How do we apply what we learned going forward? There are many styles of retrospective format; consistently doing one after every project is more important than style.