Presentation is loading. Please wait.

Presentation is loading. Please wait.

DRUPAL COMMERCE GROUP-BUY A Case Study Disaster. IN BRIEF WHAT COULD HAVE SAVED US:  Client expectation management  More careful evaluation of dev modules.

Similar presentations


Presentation on theme: "DRUPAL COMMERCE GROUP-BUY A Case Study Disaster. IN BRIEF WHAT COULD HAVE SAVED US:  Client expectation management  More careful evaluation of dev modules."— Presentation transcript:

1 DRUPAL COMMERCE GROUP-BUY A Case Study Disaster

2 IN BRIEF WHAT COULD HAVE SAVED US:  Client expectation management  More careful evaluation of dev modules  Project size estimation Intro

3 INTRO / DISCLAIMER  Please laugh, its all we could do in the end  Let me know if you hated it / loved it :  Some project details are obscured Intro

4 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 Intro

5 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 Intro

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

7 CLIENT EXPECTATION MANAGEMENT

8 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” Client Expectation Management

9 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” Client Expectation Management

10 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 Client Expectation Management

11 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 Client Expectation Management

12 THE EARLY MOCKUP DISASTER and other problems with transparency

13 THE 4 TH 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 4 TH 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

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 test server 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:

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 real development 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  We scheduled the 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?

51 DECISION FRAMEWORK  We now use these questions to help make the decision to re-invent the wheel or to use an existing module: Who is developing it? Have we tried it out? How frequent are the releases? How is the documentation inside and outside the code?

52 DECISION FRAMEWORK  The group-buy project did require reproducibility because we wanted to build other group-buy sites  Drupal Commerce is a general purpose ecommerce framework, which is a super set of group-buy  We did end up needing a sub-module, but we didn’t know we needed this until our scheduled was pushed.

53 DECISION FRAMEWORK  Views was not well integrated at the time, which we did not investigate properly  DC is entity driven which was important for our customization plans  We knew the guys developing it  We had only tried it out on very basic use cases  The releases were frequent  The documentation was not thorough

54 WOULD I DO IT AGAIN?  Absolutely  If we had answered those questions first.

55 DEV MODULE PRO’S  Gripping an active development path  More active and relevant training for your staff  Active communication from the community  Developers are often reachable  You can contribute!

56 DEV MODULE CON’S  Views integration is rarely completed  Bugs are often unreported  You can not control design decisions or development team losses

57 PROJECT SIZE EXPECTATIONS

58 THE FINAL STRAW And other straws

59 THE ADMIN SOLUTION  Back in “Early Bad News” I asked: Are any specification details given after the quote unrealistic?  The answer to this questions was be the project’s final undoing  When we quoted we had been given a target price  When we wrote our requirements specification for the quote we made assumptions  Ass meet you and me.

60 THE ADMIN SOLUTION  Late specifications are given all the time and are usually negotiable  At the time of the quote The Sales Guy said that he would have PSDs for us to guide development  When we first saw them we knew that they were beyond the specifications he had given us.  But we knew we would be pretty close

61 THE ADMIN SOLUTION  When he demanded the front page be pixel perfect we put it down to our early mockup mistake  But when he demanded style matching the backend Drupal Commerce admin interface to the front page we had serious reservations  We explained that Drupal’s strengths are layout flexibility and active content

62 THE ADMIN SOLUTION  We had functionally completed the project.  This would require an additional 10 pages of theming  At this point our attitude changed  We said that we would need our invoices paid before this went ahead  This is where our journey ended.

63 THE ADMIN SOLUTION  I can not tell you much what happened beyond this for legal reasons, but you already know the punch line.

64 APPROPRIATE EXPECTATIONS Our approximations in a table

65 APPROPRIATE EXPECTATIONS Project SizeMinimum number of payments Under $10k3 $10k - $50k4 $50k - $200k6 Over $200kMonthly

66 APPROPRIATE EXPECTATIONS Project SizeSLA (max phone or reply time) Under $10k1 working day $10k - $50k12 working hours $50k - $200k6 working hours Over $200k2 working hours

67 APPROPRIATE EXPECTATIONS Project SizeReview Opportunities Under $10k2 $10k - $50k3 $50k - $200k5 Over $200kMonthly

68 QUOTE BASED ON EXPECTATIONS  People often come to us with a budget already set in their head  Sometimes this must be turned around  Adjusting quotes for people with high expectations is reasonable as an expert  Demanding clients end up asking for all the optional extras at some point the in project

69 QUOTE BASED ON EXPECTATIONS  Does the client use phrases such as: “I’m sure you will do that the right way”  Or are they saying: “We really need to work from a budget”  As an example since the infamous project we changed a quote from $400 to $ the client took it well and in the end it was exactly what it should have been

70 THE FOOD CHAIN Our value proposition

71 VALUE ANALYSIS  If we had conducted a proper Value Analysis we may have canned the project  The Sales Guy considered himself a: Sales guy Project manager Reviewer Mockup creator

72 VALUE ANALYSIS  Our core value propositions are: Sales Project management and technical communication – key differentiator Reviewing Data modeling and business logic coding Hosting  Where we were lacking at the time was: Mockup PSD Design PSD -> Theme development

73 VALUE ANALYSIS  He was taking more project dollars than warranted his position  The value duplication was high  If we had thought of him as a partner rather than a client we would have dropped the project  He promised us a stream of on-going work  What we didn’t realize is that we don’t want any of it

74 VALUE CRISIS  We sell, but he had sold  We had a good default interface, but he demanded something else  We host, but he didn’t want hosting  We accepted him as a client based on ephemeral outcomes of reputation and more sales  We had a core value crisis

75 VALUE PROPOSITION  Do you sell?  Do you create mockups?  Do you theme?  Do you model and code?  Do you host?  Do you manage projects well?

76 HIRE OR OUTSOURCE? The eternal question

77 ESTABLISHED OUTSOURCING PARTNERS  Do they have a complementary value proposition?  Are they charging appropriately?  Are they delivering in a timely fashion?  Can you rely on them in a crisis?  Can they communicate technically and professionally?  Australian vs India?

78 EXCUSES I HAVE HEARD  “The programmer responsible for your project is on his death bed”  “We have been busy on other projects”  “No one works during Diwali”  “We didn’t understand your specification”

79 OPTIONS No resort should be the last

80 CHUCK US THE BALL!  We have a list of alternate developers and their skill sets  We pass on projects if we think someone else has a higher chance of completion  We try to develop in a way that allows a smooth transition  Some developers work for lock-in.  This is only useful in the wild west  Or with problem clients  We try to avoid both

81 THE HOSPITAL PASS  Find a partner who can manage late stage problem clients: High Quoting Non-backstabbing Knows how to be the last port of call

82 IN THE END…  We failed at Client Expectation Management  We hit all of the project requirements down to the lowest specification in the quote  He still got litigious  Early in the project we should have realized it would be a liability limiting exercise  We have since heard horror stories about him

83 FIGHT OR FLIGHT  We sort legal advice  We did the equation  We took heart  We settled  And we rejoiced!

84 THANKS FOR ATTENDING Please send questions to


Download ppt "DRUPAL COMMERCE GROUP-BUY A Case Study Disaster. IN BRIEF WHAT COULD HAVE SAVED US:  Client expectation management  More careful evaluation of dev modules."

Similar presentations


Ads by Google