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:
IN BRIEF WHAT COULD HAVE SAVED US: Client expectation management More careful evaluation of dev modules Project size estimation Intro
INTRO / DISCLAIMER Please laugh, its all we could do in the end Let me know if you hated it / loved it : firstname.lastname@example.org Some project details are obscured 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 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 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. Intro
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
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
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
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
THE EARLY MOCKUP DISASTER and other problems with transparency
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
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!!!
“NO GOOD DEED GOES UNPUNISHED” mid-project quotes
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
THE HOSTING SITUATION E-commerce Group Buy Credit Card processing (PCI compliance) 4000 projected sales in the first day We recommended a new server
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
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.
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?
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
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
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
EXPECTATION MANAGEMENT WORKS! Except with The Sales Guy
BETTER PRACTICE Bad news delivery intensity should look like a nuclear decay curve
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
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.
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
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: email@example.com
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
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
THE EXCEPTIONS … MAYBE A project changes course/goal A major change request A project scope change REQUOTE!
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
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
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
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
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.
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!?
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
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
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
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
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
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
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
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
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
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?
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?
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.
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
WOULD I DO IT AGAIN? Absolutely If we had answered those questions first.
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!
DEV MODULE CON’S Views integration is rarely completed Bugs are often unreported You can not control design decisions or development team losses
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.
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
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
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.
THE ADMIN SOLUTION I can not tell you much what happened beyond this for legal reasons, but you already know the punch line.
APPROPRIATE EXPECTATIONS Our approximations in a table
APPROPRIATE EXPECTATIONS Project SizeMinimum number of payments Under $10k3 $10k - $50k4 $50k - $200k6 Over $200kMonthly
APPROPRIATE EXPECTATIONS Project SizeSLA (max phone or email reply time) Under $10k1 working day $10k - $50k12 working hours $50k - $200k6 working hours Over $200k2 working hours
APPROPRIATE EXPECTATIONS Project SizeReview Opportunities Under $10k2 $10k - $50k3 $50k - $200k5 Over $200kMonthly
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
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 $2200 - the client took it well and in the end it was exactly what it should have been
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
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
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
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
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?
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?
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”
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
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
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
FIGHT OR FLIGHT We sort legal advice We did the equation We took heart We settled And we rejoiced!
THANKS FOR ATTENDING Please send questions to firstname.lastname@example.org