A Typical Day In The Life Of A Software Development Company

You signed a big contract with your customers.

You bid on a great set of requirements that you and your customers mutually agreed upon.

You spent a week identifying all functional elements you thought you would add to the system you are about to build.

You did this at your own time and cost.

You are really hoping that the requirements don’t change when you actually start your development. In fact, many of you assume that you’ve bid on a FIXED SET OF REQUIREMENTS.

And that my friends, is a fundamental flaw in the business model offered by most Software Development Companies.

Experience Is A Great Teacher…

In the past 10years of being in business and building Software for Enterprises and Startups (startups being the worst offenders – more on that later), we have found that there is no such thing as Stable Requirements.

Any Software development company that tries to bid on a pre-decided set of requirements is setting itself up for failure, and it sucks donkey balls!

Any Software development company that tries to bid on a pre-decided set of requirements is setting itself up for failure, and it sucks donkey balls!

Many companies understand this and offer an hourly rate model, which has a negative impact on the customers. Majority of customers end up paying hundreds of thousands of dollars more than expected in revisions, bug fixes or mistakes made by developers, which they shouldn’t be paying for at all.

To conclude, you can’t enter Fixed Bid Arrangements because it negatively affects your company, and you can’t enter Hourly Rate Engagement Models because it has negative consequences for the customer.

So, if you are a Software Development Company, the Million Dollar Question is…How Do You Engage Your Customers?

The Sad State Of Software Requirements

Every Software Development Company more or less knows about this. These are some unspoken truths:

1. In a sampling of 1 Million software constructions, IBM found more than 25% changed from their initial requirements almost instantly.
2. The cost of requirement changes balloons up very rapidly. Many times, customers don’t have budgets for these changes and the onus is now on the Software Company to deliver on what was promised.
3. Vague proposals put Software Development companies in a situation can’t really crawl out of.
4. Customers do not understand “Change Control” and think changing requirements at any phase of the engagement process is OK. In fact, if you don’t agree with the customer on this small but important issue, chances are very high that your relationship with this customer is going to sour.
5. Dumping a project because you and your customer don’t see eye to eye is never a good thing for your company. In fact, it is because of this very thing that majority of Software Companies eat up these requirement changes.

Please. Please. Please. Tell Me The Solution…

So what is the solution to this huge unspoken problem that exists across Software Development? Here’s what we believe in:

1. We strongly believe that the problem lies in educating your customers to make them understand this ‘Myth of Stable Requirements And The Existing State Of The Software Industry’.
2. We also strongly believe that a Software Development Company should enter into a monthly flat rate model of engagement that identifies 2-4 week milestones to be accomplished that are fully paid for by the customer. Whether these 2-4 week milestones are for Product discovery, or for Software Development in an Agile manner, they are paid for fully. At the end of the 2 (or 4) week sprint, both sides formally gather and review the progress made, and add any new items uncovered to a backlog and prioritize and schedule a plan for the next 2-4 weeks.
3. Every 2 weeks, both parties formally meet and assess the progress made, and then evaluate the next steps that gets them closer to the Minimum Viable Product.
4. We have seen that you can go live faster and develop more meaningful features with this approach.

The DIDI (Discover-Ideate-Develop-Iterate) Model

 

Drum roll! Introducing the DIDI Model. This model was born out of failures at HT. Mind you, failures not in building software, we build some kick butt software, but failure in being profitable like we had thought we would be.

We believe in this model so strongly, that we’ve tested projects we’ve undertaken with and without this model.

We failed by huge margins, as high as 75% without the DIDI model. No failure when using the DIDI Model.

With the DIDI model, every product development plan is broken down into 2-4 week sprints.

These sprints include: Discovery of the Product/Features about to be built, Ideation (aka wire-framing, feasibility analysis, mockups), Development (the actual development) and Iteration (based on internal feedback – usually done in the last week of the sprint).

At the end of the sprint, you have something that is fully functional, mutually agreed upon, and aligned with your overall vision for the product.

To read more about our DIDI Model, please read this.

Startups – The Worst Offenders

We feel startups are the worst offenders because they do not have the clarity of vision initially and engage development companies too early in the process and burn cash building the wrong things. There are always exceptions, yes, but we’ve noticed this trend across the board. And it hurts Software Development Companies a lot.

As a side note, we highly recommend startups to use the Business Canvas and understand their business more closely.

Many times, the enthusiasm of the product owners often drowns pragmatism and destroys any chance of building better product-market fit products. We have seen this again and again.

Many times, the enthusiasm of the product owners often drowns pragmatism and destroys any chance of building better product-market fit products.

Startups are worse than Enterprises because Enterprises have more financial resources than startups.

Software Companies have lost tons of revenue and burned their books because startups are eventually unable to pay for development costs. I personally know more than 3 companies that have been burnt by this model. One of them is/was us.

Be A Chameleon – Become Your Customer

The only way to successfully deliver a product for your customer is to become them. Yes, you read that right. For the duration of the engagement, work extremely closely with your customer.

If you’re following the DIDI model, your Customers will be a part of your daily stand-ups, your discovery process, nightly builds and releases and your primary feedback providers.

Let them see the caterpillar turn into a butterfly. They will probably value you even more after they see the effort it takes to build a quality product.

The Pros of DIDI

1. Expectations are set upfront
2. Constant Iteration = Better Product
3. Built for Change – Real World Demands Adaptability to Change. DIDI Solves It
4. Built to minimize Risk
5. Built to reduce Costs
6. Faster Delivery – Guaranteed.
7. Weeds out unnecessary features

Cons of DIDI

1. Some customers demand Waterfall Approach – You might lose some customers
2. Some customers freak out when they see early prototypes – Important to manage expectations. Never forget to tell them that they are going to see something that sucks, but it will turn into something great soon!
3. Educating Customers is difficult – emphasize on results

We are eager to hear what other Software Development Companies have used and what has worked/not worked.