drupal commerce group-buy
DESCRIPTION
Drupal Commerce Group-Buy. A Case Study Disaster. Intro. In brief what could have saved us:. Client expectation m anagement More careful evaluation of dev modules Project size estimation. Intro. Intro / Disclaimer. Please laugh, its all we could do in the end - PowerPoint PPT PresentationTRANSCRIPT
DRUPAL COMMERCEGROUP-BUY
A Case Study Disaster
IN BRIEFWHAT 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 : [email protected]
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
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”
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 4T H 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 4T H 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.
OUR BAD NEWS CURVE
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 protected]
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
LIVING ON THE DEV
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
PROJECT SIZE EXPECTATIONS
THE FINAL STRAW
And other straws
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 Size Minimum number of payments
Under $10k 3
$10k - $50k 4
$50k - $200k 6
Over $200k Monthly
APPROPRIATE EXPECTATIONS
Project Size SLA (max phone or email reply time)
Under $10k 1 working day
$10k - $50k 12 working hours
$50k - $200k 6 working hours
Over $200k 2 working hours
APPROPRIATE EXPECTATIONS
Project Size Review Opportunities
Under $10k 2
$10k - $50k 3
$50k - $200k 5
Over $200k Monthly
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
THE FOOD CHAIN
Our value proposition
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?
HIRE OR OUTSOURCE?
The eternal question
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”
OPTIONS
No resort should be the last
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 [email protected]