Skip to main content
Menu

How to fail in a Drupal project: Fixed price contracts

I hear it way too often: "Yes, we would like to do agile. Can we do a contract with fixed price? We also want fixed schedule and scope." - This leads me into explaining why that's not going to work and why it's missing the primary point of agile. One of the central ideas of agile is focusing on creating value instead of just checking boxes in a fifty page requirements definition.

In my experience there are more companies calling their design first process agile than companies doing real agile. This applies to both vendors and customers alike. Agile principles are simple, but also difficult to implement in a traditional corporate environment. To simplify the terminology I will call all waterfall models, any sort of fake agile and anything with fixed price, scope and schedule in general as design first approach.





iron-triangle.png




For past 10 years+ there has been plenty of evidence that complex IT projects have a high rate of failure with design first approach. I've written about this in the past and the point has been proven over and over again so I'm going to skip this part and move to why and first steps on how to fix this.

Why do fixed price projects fail?

When a designer creates detailed wireframes or mockups everything is cheap to implement. The cost of creating great ideas is just a few clicks and years of experience. A top designer can create really stunning designs that can be used to justify a project implementation budget. People buy into a design document because it's well documented, the professional who created it has a great track record and it simply feels right.
 
That's all great, right?
 
Not exactly. There are number of key problems with this approach:
  1. Quality is typically worse. Even the best designer can't produce as good results with mockups as she could with multiple iterations with real live prototype and user feedback.
  2. Time to market is slower. Instead of spending all that time in design phase you could have already produced the first minimum viable product with the most valuable features in it. Detailed design can also slow down implementation by drawing attention on preparing for implementing low value features that should not be implemented at all.
  3. Value generated by the project is likely to be lower. Estimating effort required for each feature is very difficult with only a design, sites can be too complicated to document. If you capture all details and interactions you've actually already built the site once. Inaccurate estimates or no estimates at all lead into designing features that are more expensive to implement than their real business value.
  4. Instead of using lessons learned during the project the team focuses on implementing stuff that has already been designed. In the worst case creator of the original design is hired to check that the end results match the original design instead of working as part of the team to start with.
  5. The more accurate the document or pilot is, more it draws attention to details early in the project when the focus should be on the big picture. It's always easier to focus details like user interface, fonts and layout than the ultimate business goals.
  • (Bonus) Responsive and mobile first design makes design first approach even more problematic. The amount of required design work is multiplied when dealing with large number of different screen sizes, contexts and use cases.
Procurement departments and lawyers in many companies love to do fixed everything contracts because they think long list of requirements are there to protect the customer. In real life these lists become protection for the vendor because they know it's enough to check the boxes and can focus on minimising the effort required instead of maximising business value created. With strict contracts the requirements are often met, but the value generated may be far from optimal.





design-traditional-agile.png




Agile doesn't remove the design, it just does it just in time instead of all up front. This leads into superior quality, value and faster time to market.

Considerations for Drupal

Drupal makes design first approach even worse. If you absolutely need to do design first projects I would recommend using a framework like Ruby on Rails or Django instead of Drupal. They are less productive when creating complex enterprise sites, but allow more flexibility with your process model.
 
With Drupal features are cheap and details expensive. Drupal is an existing tool with existing user interfaces and ways of doing things. Changing a small detail can some times take more time than implementing a fairly complicated feature.
 
Drupal is ideal for quick business level prototyping with real functionality. Just forget about the details for a while and do a quick proof of concept in a few hours. The prototype will generate new ideas, offer alternative approaches to reaching the business goal and allow us to do just in time value / effort analysis before investing into the design.





value-effort.png




With proper agile steering in place all new epic stories are always analysed based on how much value they produce. This requires a reliable estimate for the effort required and how much value the chosen approach is likely to produce. Often we get to even compare two different approaches and choosing between different designs becomes a business decision instead of design decision.
 
Taking this approach to projects not only fixes all key problems of design first approach but can also result into radically different way of doing business development and budgeting.
 
* Just to clarify the terminology: Fixed price on its own is not a bad thing at all, but since "fixed price" is sort of an established term when people mean fixed everything I'm using it to keep things simple. Why fixed price alone is often a great thing for a project is another story for another time.