How to fail in a Drupal project: Fixed price contracts

Wednesday, July 10, 2013 - 16:58

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.

Comments

I'm going to forward this article to quite a few people as it concisely expresses the difficulties of introducing Drupal working patterns to project managers who are unfamiliar with the framework and expect to be able to run the project "the way they always have".

The easy bits in their eyes can often cause hours (days?) of headaches, while traditionally difficult jobs are done in minutes in some cases.

You could switch "Drupal" with "software" as this is far from Drupal specific. Thanks for making the case.

> 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.

I would say the above is very true in my experience, but it's mitigated a fair bit by working with designers who are already very familiar with Drupal and Drupal projects. By already knowing Drupal's limitations and areas where it lacks flexibility, they can design to their knowledge of the final product's underlying technologies.

A great article, and a timely companion to the article Katherine Lawrence posted today at http://pingv.com/blog/project-of-10000-outcomes-part-one-estimating-fixe...

It was really funny to realise Katherine posting about the same topic, but from very different angle, almost exactly the same time. I simply had to comment her post right away...

I like this post a lot. By coincidence, I wrote about this on our site, http://pingv.com/blog/project-of-10000-outcomes-part-one-estimating-fixe... and came to some of the same conclusions - like bookends.

My sense is that the call for fixed bid is like someone who wants French champagne, but has a beer budget, and hopes that by putting it out for bid that somehow the French champagne will be supplied.

Just say no! No to fixed bids and no to most RFPs.

As my post (hopefully) shows that once the Drupal shop gets a realistic idea of what the client wants, there will be a lot of daylight between most fixed-budgets and "champagne dreams."

Most companies don't have the luxury of being able to say "No" to all their customers.
Yes, in the ideal Agile world, there are no fixed bids, no RFPs, just partnerships and trust. But we're not there (yet?). So in the Real World, you don't say "No", you say "Sure, but not fixed price - fixed time - fixed scope since that'll cost you quality. Let's do fixed price - fixed time - fixed quality instead and define the scope by what's most valuable as we go along".
The first time you tell a customer that, he'll most likely laugh at you and say "Nope". He'll go ahead and work with someone that promised him everything he asked for and then doesn't deliver. Next time around he'll come back to you and ask you "so how does this Agile thing work?"

Always saying "No" will prevent the pitfalls of waterfall but it'll also drive you out of business Real Fast (tm)

A project fail in the web world for many projects is being 95% done on launch day. If you are working from a fixed budget, fixed time project in a waterfall (design first), the 5% is always testing. So, you launch without testing your work. You tell the client, go check it out and let me know if you see any problems. This is a huge risk to take.

If instead, you use an agile process of arranging story iterations by business need, then the 5% is the least important features of the website. These can be turned on later simply by including them when they are complete. This is a small risk.

Your interpretation of the word "design" as you use it in "design first" is of a simplified, 'make it pretty' standpoint.

Design is PROBLEM SOLVING. In a Drupal project, or any other web project, design should always be done first.

However, UI/UX Designers and Developers should collaborate on the design before Graphic Designers add color, texture, typography, etc. ('make it pretty')

By allowing a Graphic Designer to design mockups before any user testing has been accomplished, you are not building a Minimal Viable Product. Rather, you are building a possibly useless, preconception of what you think your users want - which is the antithesis of agile development.

It's possible that we are talking about the same thing here, but I'll clarify what I meant to be sure.

I'm definitely not talking about graphical design as design. I'm talking about management consultong, service design, UX, technical design and everything around design. It makes no difference what part of the design you complete before a project you are more likely to fail in the project. Design has to be done, but it should be done just in time during the project based on priorities set by business value.

You would indeed do design first with a story, but you would not do it first for all stories.

Fixed price AND scope AND timeline work is a fallacy and nearly-guaranteed to fail. That's been proven over and over again and I don't think anyone, anywhere in the world is actually doing that. (If they are - give them some time - they'll learn or go out of business soon). So, it's a little unfair to be arguing against stupid. Stupid is stupid. Done.

However, claiming that Some Specific Process (Agile or otherwise) is the opposite of fixed price + scope + timeline, and therefore, the Only Way To Do Things is overly simplistic. It's like claiming "Evil is bad. I am opposed to Evil, therefore, I have found the One True Doctrine of Purity and Light. Believe or Be Damned!"

I think of Agile as the principles from the the agile manifesto - http://agilemanifesto.org. That manifesto is explicitly suspicious of any rigid doctrinaire process - the second point (of four total!) is "[We value] individuals and interactions over processes and tools".

I wonder if some of the original authors of the manifesto might look at some of the things done in the name of Agile and shudder. The siren-song of assuming that a Specific Agile Process solves all problems leads to a situation where once again a Process has been allowed to subvert the understanding that comes from individuals and interactions.

For example, paper prototyping - http://en.wikipedia.org/wiki/Paper_prototyping - can be an incredibly valuable tool. But - it doesn't deliver software - all it delivers is insight and understanding to client and dev shop alike. That's plausibly outlawed in some Agile processes, especially because it involves the use of the Highly Suspect Paper Format. Some of that paper even has boxes and lines on it. That might be construed as Waterfall by your definition - because N iteration(s) are allowed to happen on paper instead of in software. (That's "Design First", right?)

I think the real world is a little more complex. Drupal is a tool. Processes are tools. Tools can be wielded well or badly, especially by those who don't understand the nuances, strengths and weaknesses of those tools. We use Drupal. We attempt to tailor our processes and steps differently per the situation and needs of our clients. We sometimes do fixed bids. We often commit to timelines. We almost always put things down on paper before we start to build. We have happy clients, successful sites and a long track record. Is that Waterfall? Agile? I don't honestly know what either of those words are intended to mean any more - at least as they're commonly used. All I know is that we firmly identify with the principles of Agile yet often disagree with some of things done (or said) in it's name:

[We] value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

http://agilemanifesto.org

I fully agree that this is an oversimplification. Real life is much more complex, but in order to make a point about a complex thing in a short blog post simplification is always required.

However saying that everybody already knows that fixed everything is a bad idea and nobody does that anymore is quite far from the truth. My guess is that 80..90% of vendor - client relationships in the IT world are still around fixed everything model. This is the overwhelming feedback I get when talking about agile in different (other than agile) events.

I think there is still a LOT of work to be done before most projects follow agile principles.

Fair enough. We've been fortunate enough to be able to avoid those kinds of conversations for a while - if I were seeing 80-90% fixed everything I'd be pretty unhappy about that stupidity. Fight the good fight!

Most of our larger jobs are with established clients, and we have been moving them towards an Agile/Scrum approach for a while, largely successfully.

With everything else, we only bid as a range, and we bill time and materials. We have had very little resistance to this approach, which leads me to believe that the companies we compete with are doing much the same thing. While there is some risk (I have yet to bid the range $1 - ∞), it is reduced.

True story.
I'm a drupal developer, and every project is the same pitfall.