Drupal Commerce Group-Buy

1. Drupal CommerceGroup-Buy A Case Study Disaster

2. Intro In briefwhat could have saved us: • Client expectation management • More careful evaluation of dev modules • Project size estimation

3. Intro Intro / Disclaimer • Please laugh, its all we could do in the end • Let me know if you hated it / loved it : john@evelops.com • Some project details are obscured

4. Intro On a dark and stormy night • When entities were at the bleeding edge of object oriented Drupal development • Drupal 7 had just gone gold • A tail of development woe begins • There were no winners • But I can tell you somewhat accurately how badly we lost

5. Intro Our Dues • 80 hours of project management • 160 hours of development time • 3 external developers managed • 4 months of heart ache • 2 heads banging repeatedly against a wall

6. Intro Today’s Mode • I hate hubris • I will try not to ‘teach’ • The way we learnt from this was to implement systems • So that is how I will explain our lessons • But I will try to keep to the story • If you kill 3 projects … Win.

7. Client Expectation Management

8. Client Expectation Management Direct Client Communication • I will start with out biggest mistake • We never were in direct contact with our real client • I now understand what it is like to be an Indian developer • Out client was “The Sales Guy”

9. Client Expectation Management The Sales Guy • Well branded seemingly experienced design shop owner • Sharp, well dressed, well versed in tech speak • Found us on a php mailing list • Presented us with “an opportunity”

10. Client Expectation Management Our misconceptions • The sales guy was our technical communication buffer • The sales guy would be our ongoing development project faucet • The sales guy would care about our branding or reputation

11. Client Expectation Management The harsh reality • Two sets of client priorities, one delivered second hand • Duplication of our value proposition • Responsibility with no representation • Our brand took the blame • One massive ego with his client expectation management on backwards

12. The early mockup disaster and other problems with transparency

13. The 4th Party • We contracted an Indian developer to do the PSD to theme development • We opened up our development process to The Sales Guy • In the first week they gave us a flat html template mockup which sat nicely on top of Drupal • Pixel perfect front page, but no blocks or regions

14. The 4th Party • This is a great way to start INTERNALLY • The Sales Guy showed this to the client… • The client was Ecstatic • SITE DONE • Only a couple of pages to go!!!

15. “No good deed goes unpunished” mid-project quotes

16. The Hosting Situation • The “Production Server” was: • A shared host • Had old versions of LAMP • Was in the US • Was slow • No Varnish • No Memcache • No APC

17. The Hosting situation • E-commerce Group Buy • Credit Card processing (PCI compliance) • 4000 projected sales in the first day • We recommended a new server

18. The Hosting Situation • The Sales Guy insisted on using a particular VPS solution • We offered our installation services “at our normal development rate” • The sales guy accepted via email

19. The Hosting Situation • We installed a complex LAMP setup on a RHEL 5 server • We set up bespoke access and security • We optimized for Drupal • We forgot about it.

20. The Hosting Solution • When we included it on an invoice he was outraged. • “You suggested it” “I thought you only meant a longer schedule” “It should be included in the project price” • Expectation management fail?

21. The Hosting Solution • At this point we were self doubting… • Does he live in a reality distortion field or did we not engage in adequate client expectation management? • We took this on the chin with these lessons: • Formal quotes for side projects • Invoice side projects early • Insist on production server specifications early

22. Not the dev code!? • Near the middle of the project The Sales Guy chose to get a third party developer to pronounce our code un-fit for production • He had the developer login to our testserver to look at the code • We could have told him it was un-fit! • In this case he was being vexatious and hinting at litigious to put us under pressure

23. Not the Dev code!? • At the time we laughed it off and set him straight • We know the developer and he didn’t get paid • It was at this point we should have switched from expectation management to a hospital pass

24. Expectation Management Works! Except with The Sales Guy

25. Better practice • Bad news delivery intensity should look like a nuclear decay curve

26. Early Bad News • Give them bad news early • We want money for that job • Its going to cost you more than you thought and here’s why • PS: Before we start we need that deposit in our account

27. Early Bad News The bad news is that it is going to cost more than you expected and a bunch of unexpected setbacks will occur because of scope mis-interpretation and expectation mis-matches, which will blow out the schedule. The good news is that we have created something we can both be proud of, which includes all the brilliant features.

28. Our bad news curve

29. Early Bad News • In the beginning the client usually is relaxed • It always seems a shame to spoil that, but: • They rarely have realistic expectations • They need to be tamed for trickier issues, which will come later • This is the time to sort the low hanging fruit from The Sales Guy

30. Early Bad News • If there is no bad news, Great! But check these: • Did they pay the deposit quickly? • Are they treating your technical suggestions with respect? • Are they quick to answer your questions? • Are any specification details given after the quote unrealistic? We will get back to this… • Can you think of other universal bad client indicators: john@evelops.com

31. Mid Project Bad News • If mid project you are not hitting your own development targets … tell your client • You will have a better idea of the realdevelopment time • If this is because of scope creep you will probably have enough evidence to re-quote • If you re-quote and they want to terminate, see our early termination clauses

32. End Project Bad News • This is the WORST! • The client remembers it bitterly • It makes you look the most unprofessional • It makes it tempting for the client to try to wriggle out of the final payment … goodbye profit margin

33. The Exceptions … Maybe • A project changes course/goal • A major change request • A project scope change • REQUOTE!

34. The Credit Card Solution • We thought we had learned our lesson • We were determined to handle any more change requests by the book • Re-quote / Re-schedule / Under-promise

35. The Credit Card Solution • Original spec called for a completely integrated SOAP solution • We had suggested a payment processor • They had decided on a different processor • There was no existing Drupal Commerce integration • Asking for testing access from a processor is tricky when the client doesn’t know your name. • Eventually we obtained a developer account from the processor

36. The Credit Card Solution • The integration was working brilliantly when their bank decided that they would only allow them a merchant account if they used a hosted solution… • This change request came in two weeks before delivery • The Sales Guy told us to put everything on hold to get this working

37. The Credit Card Solution • We re-quoted • We re-scheduled, blowing out our launch date • We clarified that they wanted a hosted solution based on a POST redirect • We clarified what “hosted”, “POST” and “redirect” meant • The Sales Guy agreed to the quote and assured us that this was what they needed

38. The Credit Card Solution • We completed the solution and proudly showed The Sales Guy within the beta site • He was pleased and took the solution to the invisible client • They were not pleased. • Once again reverse client expectation management was working against us.

39. The Credit Card Solution • The invisible client had never been told that there would be redirection • They wanted all the magic to happen within the bounds of their site and their branding… • At first The Sales Guy was apologetic • Then he insisted we should have implemented the hosted solution as a frame!?

40. The Credit Card Solution • At this point knew he lived in a reality distortion field • We are generally against frames, but it was late in the project and we wanted to get paid • So we implemented. • And invoiced • And waited

41. Living on the Dev

42. Drupal Commerce is Awesome! • Disclaimer: • This is not a dig a Drupal Commerce • I love those guys • We have implemented DC successfully since • This is a criticism of our evaluation of using particular dev modules • When Drupal Commerce got to 1.0 it still relied on dev versions of modules

43. Why Drupal Commerce? • DC seemed like the shortest way to OO Cart bliss • We had met the DC guys at Drupal Con and thought they were awesome • We were planning many ecommerce projects and wanted our developers and admin staff using the latest and greatest

44. The Plan • The cart was very interface heavy • Planned out our data model then handed over to the themers • Wescheduledthe business logic development later in the project to co-inside with the planned stable releases of DC

45. A Problem • DC relied on the dev version of views and lacked good reporting defaults. • Our more specific problem was tracking sales • Every group-buy site needs to show how many sales have been made for a particular deal on the front of the site

46. A Problem • The Views 3 interface changed three times during the project • Dev Views came with its own set of unreported bugs • The Rock: No obvious way to aggregate number of completed Orders for a particular Product • The Hard Place: Creating a custom reporting module might blow our budget

47. The Solution • We found a post on drupal.org describing exactly the same problem • Ryan had posted acknowledging the problem, but was not ready with an answer • We posted a possible solution • It turned out three other Drupal shops were having exactly the same problem who promptly contacted us • Our compromise was to create a very simple custom field which could be attached to the product entity

48. The Solution • We have published the module • This is not the definitive solution • The process which was most valuable was communicating with the other Drupal shops about requirements that should be considered and approaches that could be tried

49. The Lesson • We thought we could rely on a newly released stable version 1 module with dev dependencies to help speed up our cart development • We needed to more fully research the current weakness of DC

50. Decision Framework • We now use these questions to help make the decision to re-invent the wheel or to use an existing module: • Are we building for reproducibility? • Is the module a more general form of the functionality we need? • Do we need to build a sub-module? • Is it fully exposed to views with good defaults? • Is it entity driven?