DRUPAL COMMERCE GROUP-BUY A Case Study Disaster. IN BRIEF WHAT COULD HAVE SAVED US: Client...
-
Upload
ira-french -
Category
Documents
-
view
213 -
download
0
Transcript of DRUPAL COMMERCE GROUP-BUY A Case Study Disaster. IN BRIEF WHAT COULD HAVE SAVED US: Client...
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]