Fixed Budget Drupal Projects: The Art of Estimates
•Als PPT, PDF herunterladen•
10 gefällt mir•5,461 views
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...
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (10)
Ähnlich wie Fixed Budget Drupal Projects: The Art of Estimates
Ähnlich wie Fixed Budget Drupal Projects: The Art of Estimates (20)
Mehr von Adyax
Mehr von Adyax (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Fixed Budget Drupal Projects: The Art of Estimates
- 1. Business & Strategy · Maxime Topolov @mtopolov · 24 September 2013 DRUPAL FIXED BUDGET PROJECTS: THE ART OF ESTIMATES
- 2. 100 Drupal Experts 50 projects per year @adyax
- 7. 4 tasks job
- 12. "Some things are so unexpected that no one is prepared for them." -- Leo Rosten
- 13. Estimated by senior, done by junior
- 14. Perimeter misunderstanding or changesPerimeter misunderstanding or changes
- 15. Human factor
- 16. What do we need to estimate ? What do we need to estimate ?
- 17. 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
- 18. 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.
- 20. Drupal & modules install and setup S1 : 2 to 3 days S2 : 4 to 7 days S3 : 8 to 15 days
- 21. Couple of days to setup : Redmine, Users, Mailing lists, etc...
- 23. SEO, URL, page titles, ads, analytics S1 : 3 days S2 : 5 days S3 : 10 days
- 25. why templates are so important TasksTasks HoursHours F1F1 HoursHours F2F2 HoursHours F3F3 Sketching 1 2 4 Wireframes & validation 2 4 8 Design 4 10 16 HTML 3 6 16 Drupal templating* 8 12 16 SCARY TOTALS 18 24 60 * complete bullshit, since Drupal templating strongly depends on features
- 26. Data migration
- 27. Data migration per content type From Drupal : 1 day From Structured DB : 2-3 days From HTML : hell
- 29. EACH DEPLOY COSTs YOU $$$ Drupal Clouds* : 0,5 days Capistrano like : 1 day Old School : 3 days * Acquia Managed Cloud, Commerce Platform, Pantheon
- 30. Tests & QATests & QA
- 31. how much you test ? S1 : 15% dev days S2 : 20% dev days S3 : 25 to 30% dev days
- 32. Management
- 33. how much time to manage S1 : 10% dev+qa days S2 : 15% dev+qa days S3 : 25% dev+qa days
- 34. Specifications
- 35. How much specifications S1 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+
- 36. Wait...
- 37. FEATURESFEATURES
- 40. 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...
- 42. 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 ?)
- 44. page centric RFPs Easy to get features You almost have to imagine the templates, contexts and probably back-office features would not be described.
- 45. COSTS
- 46. HIDDEN COSTS Back-office clean up and theming Workflow, notifications and user permissions WYSIYWG setup, CSS clean up Optimisations and architecture fine tuning
- 47. How to avoid being the most expensive bidder.
- 48. 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)
- 51. 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)
- 53. project ‘backlog’ Your quote data Actual project data
- 54. sprint ‘backlog’
- 55. 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...)
- 56. Credits & Debits how to manage change requests keeping client happy Credits & Debits how to manage change requests keeping client happy
- 57. credits & debits doc
- 58. 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)
- 59. The STOP day.The STOP day.
- 60. Never ending acceptanceNever ending acceptance
- 61. 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.
- 63. 100 Drupal Experts 50 projects per year @adyax
- 64. THANK YOU! WHAT DID YOU THINK? Locate this session at the DrupalCon Prague website: http://prague2013.drupal.org/schedule Click the “Take the survey” link
Hinweis der Redaktion
- Estimates are probably the most dangerous work a project manager do. Many projects are late, we even say that 70% of IT projects are late. Doing fixed budget projects, you may loose money.
- Everybody here knows the scary deadline. Approaching. And most of the time deadlines are not met.
- So after a while deadlines are not so dead and scary. Is meeting deadlines and make right estimates is really impossible ? After all, we're smart guys, you all here, you do Drupal, so you ARE smart. And we do crazy things. We do Panels, Views we even understand how to create a module in Drupal 8. We're experienced developers or project managers. But wait, you do estimates in every day life, and you do them pretty well. Imagine you're in Prague, with a good Drupal friend.
- He call's you in here, and says wazaaaaa.... hum, says let's have a glass of wine in the best bar in Prague. He gives you the address and what do you do ?
- You'll probably open google maps, check how to get there, time you'll need. Add some extra time in case of any unpredictable problems.And usually, you'll be on time.
- Not always. Everyone here knows some friends who're always late. Actually what make us late, in every day life, are errors in estimates and unpredictable events.
- If you want never being late, you should add risks and estimate impact of risks over your plan.
- For example : how long will it take to get to my bar if there is a strike and I have to go there walking.But you should also estimate the chances of actually this particular risk will happen and apply this percentage to your estimates. With all possible events. The problem of this approach is that some risks have unfinite consequences on your journey.
- As said Leo Rosten, "Some things are so unexpected that no one is prepared for them." But let's being honest, during a Drupal project you have a limited amount of events making your estimates going wrong :
- The first thing your developpers will work on, is Drupal & modules setup and content structure definition. Of course depending of site complexity you'll spent more or less time. We do not try to go deeply in details. But you'll need time to install this bulk set of modules, you eventually can speed up the process going with a distribution.
- This is an exactly example of hidden costs. You setup a ticketing system with your client, create user accounts, setup GIT repository, branches, install your developpment server or create a pantheon or commerce guys platform. But you'll spend time on this too.
- Contexts, you'll have a lot of small work to do with contexts. SEO, Analytics tag plan, Advertisement, Page titles, URLs, all rely on context. More contexts you have more work you'll have to produce. I rember this client we got. Big french machines rental company, Kiloutou. While we were in last stages of project release, you know those 2 weeks sprints that lasts 2 months... well we asked this client to send us tags plan. Site was a 30 templates e-commerce site. We got a 70 pages specifications and 300 tags to implements on pages, but also on clicks, actions, and different checkout scenarios. God, we spent 2 weeks implementing it. So be careful with contexts related tasks as they are directly linked to the number of templates.
- Now we'll talk about something very special. Something that from my point of view gives you the most accurate way to measure the site's size. The templates. Templates are so important because while creating a brand new website you will there are so many people and time used on each of them, it always freaks me out.
- You start sketching the product page, you sketch in all 3 responsive versions, then you probably try to make validations, backs and forths with the client so you create 3 wireframes. Finally, after that your designer will produce PSDs (again to validate them with the client), finally you'll produce statics HTML of each template to test on so many devices you sold to your clients (yeah rember during the presales phase when you actually said that this responsive will work even on a Nokia 3310, they finally silently added nokia's support to the contract). Then your drupal developer will work on implementing it in drupal. Finally. Let's see some metrics. Those numbers are some kind of empiric values from 250 projects we've done so far in Adyax.
- Very diffcult to estimate but usually you spend from 2 to 5 days per content type depending of the source easiest from Drupal to Drupal, then from a highly structured DB to Drupal, and finally the worse, from unstructured HTML (with those so easy structure, if you have a <P> tag put is as teaser, and then, always, promise, always a <strong> means sub-title, hum, yeah really really all our contributors try to respect those rules... since 5 years....).
- Deploy is always a big debate. If you're running on Acquia, Pantheon or Commerce Platform you can almost do continuous integration stuff and each deploy will take you minutes. On more classical hosters it will depends of the deploy policy you've setup with your client. So alway take this in account at early stages of the project. I got a big customer and we agreed to deploy after each sprint, so we agreed on 12 deploys. The problem was the client was running his live environemnt with an old school very big hosting company, who deploy manually using a tar.gz files on an FTP. Making errors during each and arguing it was our fault. We spent 25 man days on deploys. But wait, we said that deploying on Acquia, Pantheon or Commerce Platform would take minutes, that's not exactly truth. Deploy means, write down release notes (export deployed tickets from redmine for example), prepare your features, write some module_update functions, test the deploy, and THEN deploy. It take time. Usually each deploy
- I do wonder why developers do bugs. They do, and that's why we need testers. How many of you have dedicated test teams ? ... Actually that might be developers doing QA or dedicated, doesn't really matters. What we've actually noticed is that testing is directly related to developpment time. It takes from 15 up 30 percent depending of site complexity. I include and mix here manual and automated testing.
- Here again many variants are possible. A freelancer project may not require any management at all, while a big project envolving 10 developpers may require several project managers. But again, even a freelancer does some management work. The hard thing in estimation of management is the fact that management efforts depend not only from the project, not even from the knowledge level of your team, but from the kind of the client you have.
- You know I had a project, an invite only community site, and the client was like 5 persons without any knowledge of the web stuff at all. Thoses are usually spotted by us, but we don't know why we accepted this project and the nightmare lasted for several months... Like why the site is not opening when i enter the url [email_address] . Those kind of clients may make you loose money, if you can avoid them just do it. Best processes cann't nothing against human factor.
- Do you write specifications ? For all of your projects ? Say the truth. I think that agile did a lot against specifications. Actually I think that specs are the most important thing that will save your margins. You can write specs at the begingin of the project, or do it sprint by sprint, but you need to describe entirely the project by specs. And make sure you validate them with the client. This is the only way to decide what's in the scope what's not, what's a bug and what's a feature. I think even small project need specs. And large project need specs being constantly updated as they'll also serve as project documentation. If you don't want to lose money, write specs for all projects.
- But wait, guys. What about features.
- I mean those things that make your project unique. There is not only modules and templates. There are a lot of business logic, small or complex features. There are no rules of estimate of those things. The only way is to divide the features into small parts, templates, find modules that you could use and try to estimate the time for each part. As for the rest, the more precise you'll be the more accurate will be your estimates. For example for a "voting feature" you should estimate how long it would take to install and configure Voting API, FiveStars, do the theming for the fivestars, add some custom blocs, theme them, test everything, apply updates on content types, etc...
- Your project is live, client finished paying doesn't mean you finished spending money. The client will call you and while during the project it’s ok and probably included in specifications, project managemment and stuff. Once your project is live, how do you deal with support ? You guys once your project is live if the client calls you in ? Well the problem with the support is the fact that it’s so close to the commercial relationship you’ve setup with your client, so you cannot bill easily that. I mean you cannot say when the client has spent 6 month with you on the phone that you’ll not take his next call because he did not took the support. So the right thing to do is to prepare the client from the very beging of the project and explain your support policy. You can go for a global fixed annual price or a ticket based system, but the most important is to prepare you client from the begining of the project or even during the presales phase.