Embed Size (px)
DESCRIPTION
Session given during the Drupal Con Prague 2013. https://prague2013.drupal.org/session/drupal-fixed-budget-projects-art-estimates In many countries accross Europe, websites projects are bought using fixed budget engagements from vendors. RFPs we receive have often a very poor level of details, while client still wait for a fixed budget and timeframe. During this session we'll present how we do at Adyax, bidding on fixed budget projects only to ensure that projects are always delivered and we get some money for it. Session will cover several key points, like : How to analyse and RFP and convert it to a Drupal Project Plan How to count templates and related charges Reading between the RFPs lines, detect those features that are not clearly described How to avoid being the most expensive bidder by providing options Some sharing about our estimation rules, tips & tricks How to prepare a detailled planning Important risks that can blow up your margins In what Drupal is so different from others CMS / Frameworks How to keep an eye, during the project on your margin How to deal with change requests and evolutions How to make your customer happy even when you ask them more money and/or time 10 usual mistakes that any Drupal Shop do. Session will be supported with a set of concrete examples...
Citation preview
Business & Strategy · Maxime Topolov @mtopolov · 24 September 2013
DRUPAL FIXED BUDGET PROJECTS:
THE ART OF ESTIMATES
100 Drupal Experts50 projects per year
@adyax
Forecasting & Estimates
4 tasks job
"Some things are so unexpected that no one
is prepared for them."-- Leo Rosten
Estimated by senior, done by
junior
Perimeter misunderstanding or changes
Human factor
What do we need to estimate ?
S1 : Simple site : no authenticated trafic, less than 10 content types, less than 20 templates, no external data flow, no or simple workflow
S2 : Medium site : simple user related features like comments, voting, sharing, from 10 to 20 content types, from 20 to 50 templates, some simple XML data sources, workflow and custom business features, simple data migration
S3 : Complex site : transactional web site with high trafic (e-commerce, social network, intranets), more than 20 content types, more than 50 templates, many custom business logic and several complex data sources, advanced data migration
Site complexity s1, S2, S3
Front-end complexity F1, F2, F3
F1 : Standard desktop output. Site is mostly blocs based, structure is simple. No front-end animations, not much Javascript. No accessibility. No mobile support. IE10+, FireFox, Chrome & Safari support.
F2 : More advanced front end with a mobile version for some templates. Some basic front-end JS animations. Basic level of accessibility support. IE8+ is now supported too. iOS & Android last two versions support.
F3 : Full-responsive design with 3 break-points. Level 2 of accessibility support. IE6+ (degraded mode) support. Responsive tested in iOS, Android, Windows Phone, UC Browser, Opera mini.
Drupal & modules install and setup
S1 : 2 to 3 daysS2 : 4 to 7 daysS3 : 8 to 15 days
Couple of days to setup : Redmine,
Users,Mailing lists,
etc...
Page titles URLS
ANALYTICS
AD
PANELSMICRODATA
CONTEXTS
SEO, URL, page titles, ads, analytics
S1 : 3 daysS2 : 5 daysS3 : 10 days
TEMPLATES
why templates are so importantTasksTasks Hours Hours F1F1 Hours Hours F2F2 Hours Hours F3F3
Sketching 1 2 4Wireframes &
validation2 4 8
Design 4 10 16HTML 3 6 16
Drupal templating* 8 12 16SCARY
TOTALS18 24 60
* complete bullshit, since Drupal templating strongly depends on features
Data migration
Data migration per content type
From Drupal : 1 dayFrom Structured DB : 2-3 daysFrom HTML : hell
EACH DEPLOY COSTs YOU $$$
Drupal Clouds* : 0,5 daysCapistrano like : 1 dayOld School : 3 days
* Acquia Managed Cloud, Commerce Platform, Pantheon
Tests & QA
how much you test ?
S1 : 15% dev daysS2 : 20% dev daysS3 : 25 to 30% dev days
Management
how much time to manage
S1 : 10% dev+qa daysS2 : 15% dev+qa daysS3 : 25% dev+qa days
Specifications
How much specificationsS1 DaysS1 Days S2 DaysS2 Days S3 DaysS3 Days
Content types 2 4 7+External systems 0 3 10+
Workflow 0 1 5+User related
features 0 2 5+Back-office 1 3 5+
Front-end 3 5 15+SEO & Analytics 0,5 1 5+Data migration 0 4 15+
Search 1 3 5+
Wait...
FEATURES
UserCentricRFPs
User centric RFP
Detailled presentation of features...
...but spreaded across several user stories.
You’ll need to be careful with templates and site structure...
...and with SEO, Analytics, Contexts, etc...
PageCentricRFPs
page centric RFPs
Easy to count templates
You’ll need to be carefull with business rules (why this magic bloc actually appears on that particular page) and the back-office (you need a dashboard for that ? really ?)
Features ListRFPs
page centric RFPs
Easy to get features
You almost have to imagine the templates, contexts and probably back-office features would not be described.
COSTS
HIDDEN COSTS
Back-office clean up and theming
Workflow, notifications and user permissions
WYSIYWG setup, CSS clean up
Optimisations and architecture fine tuning
How to avoid being the most expensive bidder.
avoid being the most expensive
Be precise in your quotes. Describe exactly what you’ll do. Usual number of rows in a quote : 20 (S1), 50 (S2) or 100 (S3)
Add as much options as you can.
In case of unclear feature, take low level estimate and explain exactly what you’ll provide.
...or underestimate your build and bet on the run (dangerous strategy usually employed by big IT companies)
BUILD PHASE
What's measured improves
Redmine & timelogs
1 line in your quote = 1 super task in redmine
Any issue must be a subtask of a quote-based super task
Force everyone to log time daily (specially project managers)
project ‘backlog’
Your quote data Actual project data
sprint ‘backlog’
timelog take home messages
Everybody must log time
Keep the link between your initial quote and actual issues & tasks
Share estimates with developers & QA so they can warn you if you go out of scope.
Stick to the plan, even during panic periods. (Yeah, i’ll log my hours next week, we have a release now...)
Credits & Debitshow to manage change requests keeping
client happy
credits & debits doc
change requests take home messages
Being precise in the initial quote, makes life easier when you need to bill changes
If possible, don’t send many small bills but keep track of evolutions in a credit / debit shared doc
When doing evolutions quotes keep in mind that the price should include the dev of the evolution itself and the integration into the site (which actually may be more complex thant the feature itself)
The STOP day.
Never ending acceptance
avoid never ending acceptance
You do agile bla bla but yet you always have this final acceptance period.
Acceptance must be time boxed. You MUST define, with the client a precise period of acceptance.
Days / weeks before the release define with your client ‘blocker’ issues.
Explain to the client what happens during the guarantee period.
Avoid doing new not blocking features during the acceptance.
Support & Maintenance
100 Drupal Experts50 projects per year
@adyax
THANK YOU!
WHAT DID YOU THINK?
Locate this session at the DrupalCon Prague
website:http://prague2013.drupal.org/scheduleClick the “Take the survey”
link
