The hidden cost of skipping requirements

A common complaint about software development is that projects often go over-budget and take longer than originally estimated.

The sad truth is: the hourly effort of software development in almost all cases is much higher than anticipated, and certainly a lot higher than any programmer would ever admit.

While in some cases the problem is caused by the developer's incompetence and lack of experience, in most cases the problem has nothing to do with the developer. The problem is caused by the fact that there is hardly any billable effort allocated to properly assess the requirements prior to giving a "quote".


While most small to medium clients view the work as hours spend on the actual programming - building a web application, just like building a house, involves a lot more effort than simply coding or putting bricks together. In fact, coding in most cases is less than 40% of the total effort.

A typical web application development process consists of several phases, each of them requiring time (and money):
-- Planning (also called "Discovery", "Specification Development" or "Requirements Gathering")
-- Structural design
-- Implementation
-- Testing

(The phases may repeat over and over, depending on client's solidity in original requirements, market changes, new fads in the industry, and new cool ideas seen on a competitor's site).

Unfortunately there is hardly ever enough budget allocated for the first 2 phases. The client tends to be willing to just jump right into the project without giving it enough thought ("the sooner we start - the better"), and feed random ideas later, throughout the development cycle.

In the meantime, the vendor is too focused on getting to the Implementation phase, as anything prior to that is viewed as part of getting the deal.

However, the first two phases of the development cycle are often the most labor-intensive and expensive ones, as they not only involve commitment by multiple parties, but also - brain picking and time spent by the most "expensive" participants: business stake holders, project management and senior development personnel to properly understand the requirements, develop the idea and lay it down into a blueprint that best fits the client's needs as well as time and budget.

If this stage in the process is done correctly, development (implementation) is a breeze.
However, it is extremely hard to get the small-to-medium business client to pay for the pre-implementation phases. Clients simply don't want to pick up the tab for the preparation time spent prior to implementing their custom solution. And unfortunately, there are plenty of desperate vendors out there who will spend hours of unpaid time on requirements gathering, research and idea generation BEFORE the client commits to a billable project. These vendors throw the expectations out of balance and create a situation where other vendors are also expected to develop a business process and other intellectual property for free in hopes of getting to the billable implementation phase. So what happens what you are forced into completing a good chunk of work for free in order to get that bid? Most likely you are not going to put forth enough effort to property assess all the details. As a result, the estimated project cost is likely to be just a number you gamble on.

Ideally, in today's world where choices and possibilities are overwhelming, and you have to be top-notch or else - a vendor should be paid a good chunk of money to review the project and do the proper research to sketch out the best solution and brain-storm on ideas before committing to any budget. In other words, the vendor should be paid for responding to an RFP.

Yet, most IT deals in the small to medium business world work in the pattern of rushed "guestimates".

Guess what? If you are not paying the vendor to do job one, but there is a potential to get job two, the vendor will complete job one for free with as little effort as possible, just to get that job two. Once the vendor gets job two and realizes that the original "guestimate" is way below the real cost, he has several choices:
-- insert hidden costs to make up for time spent on job one behind the scenes
-- complete the job two according to the vendor standards and resent any input from the client in an "out of scope" verdict fashion
-- inform the client half-way into the project that the work is going to take a lot longer and cost a lot more

The IT industry has been around long enough to establish methodologies, coding practices, etc. Yet, unlike the building industry, the idea that you have to develop (and pay for!) a blueprint for your IT solution before commiting to any budget has not sunk in for many clients. Would you ever ask a construction company to propose a budget on a new house without a blueprint? Would a construction company even talk about budget without assigning an architect to the site first?
What seems to be ridiculous in an established industry is still a common practice in the IT world that serves small to medium businesses.

What about the larger businesses? Once the deal is signed, the vendor is not going to be shy about blowing up the scope once any small change request creeps in. Larger businesses are more likely to easily accept (and pay for) scope changes, which gives the vendor a chance to get paid for all the hidden work.

When offshore experiences are not amusing..

A few years ago I visited a certain Latin American country. Looking for something to do off the beaten track we decided to take a trip to a small village on the coast, about a 100 km from the hotel we were staying at. “How do I get to Choroni?”, I asked a hotel worker. She told me that I need to go by bus the next morning, I can arrive at the bus stop at any time and just wait for the bus since they run every 30 minutes. We made that a plan for the next day, but just to verify, I asked another hotel worker the same question: “How do I get to Choroni?”. With much confidence he responded that the buses to Choroni only run on the weekends, and I should consider getting a cab. Somewhat confused, I asked another hotel worker the very same question. And her advice was to get to the bus station before 1pm and get a ticket since the bus leaves once a day in the afternoon.

Confusing? Perhaps. As it turns out, in their culture to admit that you simply don’t have the answer is considered rude. Providing some solution (even the wrong one) is a much more polite thing to do than to say nothing.

Annoying? Perhaps. But when you are on vacation enjoying food and wine and exploring a new country, such cultural differences in the end are nothing but amusing stories you talk about later.

But when business deadlines are missed and problems snowball, cultural differences between you and your offshore business partner are not that amusing anymore. You are not just experiencing the foreign culture at your leisure – your business is at stake.

Here is an interesting article, written by Dr. Karine Schomer, who talks about some of the differences between Indian and American business cultures, and how they affect your offshore outsourcing experience.

"Fixed bid" vs "Agile"

Web 2.0 is the most overloaded term, yet agile development is a reality in today's rapidly changing world where new options pop up every day, yet the client's time is overbooked and thinking is often forced into "lets just get started on this, we'll think about it later".

The mismatch comes when a US-based client operating in a fast-paced business-environment expects the app development process to be "agile" (meaning multiple short iterations in development cycle where 50% of yesterday's requirements may be thrown out the window and be replaced with features that the client saw on a competitor's site today).

Yet, with outsourcing, and with the lack of control over the people overseas, a semi-fixed bid is almost always expected. In fact, who would accept a bid from an offshore company if the final cost is undefined?

So your oursourcing team is forced to operate in Discovery-Signoff-Development-Testing-Delivery mode, and it would get real nervous about changing tracks in the middle. The client has to really get their stuff together BEFORE the development begins, and any new even minor modifications become an annoyance to be postponed till next phase, as a "request for a change", at a separate (generally higher) rate.

The idea is: you need a web app done, tell me everything you need upfront. Once you sign off, the train starts rolling, and there is no stopping till we finish. And then (hope you've reserved your maintenance hours) we'll deal with you again, at a higher rate and increased timelines, because your small changes take up lots of management hours, and another "fixed bid" project from a different client is already in the pipeline.

That sounds like a bunch of whining with no solution.

An obvious solution would be to hire a dedicated team overseas. Yet, it may get costly for a smaller-size company that doesn't have enough work for even one full-time offshore developer, and whose main purpose is often to keep their current web application up-to-date and ensure responsive support and smooth transitions between future project development iterations.

Yet, a small ongoing development contract may do wonders.

1. Development hours booked and pre-paid ahead of time will let your offshore team know that you are anticipating changes and that you are serious about your work relationship.

2. Pre-paid development hours automatically get converted into expected workload in their pipeline. Meaning that at the beginning of the month your original developer's time is at least partially allocated to your next idea (assuming, of course, that the developer hasn't moved to another shop by now).

3. Generally the more hours you reserve, the cheaper your rate is (probably close to a rate you are charged for development). Cheaper rate + original developer available = seamless transition from phase to phase and more flexibility on your end to tweak things, try new ideas, see what works and what doesn't.


On the contrary, a lack of ongoing development contract (and especially, the lack of maintenance agreement) often means the following:

-- Your original developer is already booked with the next client
-- Every minor change on your part is billed at a higher rate and takes longer to implement, since the developer has to be pulled off his current deadline)
-- Your next enhancement phase may be performed by a different developer with a different coding style, who may not be familiar with all the intricacies of the project. Which leads to bugs, more management time and frustrations on your part.

A situation where noone wins in the end.

what-to-do offshoring

Once a good plan is set in place and resources are reliable, execution is easy (or at least fairly predictable).
We fly through most parts of the majority of the projects because the majority of functions of most apps are fairly predictable and similar to something we've already done.
But once you come across something you've not done before, you are faced with a lengthy research process: you have to get on Google and see what others are doing, what works and what doesn't and why.

This is where the majority of un-billable hours are spent: a client (or yourself) wants an idea developed, but neither the client nor you know exactly what to do.

Since research often is the least paying task, it would be great to get it accomplished at the cheapest rate possible thru outsourcing.

Yet "What should I do" can hardly be outsourced.

But wouldn't it be great, if the next crazy business idea that crawls into my head could be shipped off overseas for thorough analysis. So that a few weeks later i could get a detailed report that would include:
-- What potential competitors are already doing in this area, what are the strong and weak points of their products
-- What is the demand for this product
-- Potential profit markets and profit margins
-- Potential obstacles
-- What should the slick Ajax-based GUI look like
-- Any other ideas that evolved from brainstorming by entrepreneurial-type minds at a "reasonable rate"

Yet, the most time-consuming and the least billable task in the world can hardly be outsourced, at least not today.

Good post on engineering degrees

.. in tune with my previous post "Not always Top Quality Talent" - here is a great post I've found today:

“U.S. graduation statistics are readily available from the Department of Education’s National Center for Education Statistics. Extensive data on engineering education are also collected by the American Society for Engineering Education and the Engineering Workforce Commission. In order to collect similar data for China and India, we initially contacted more than 200 universities in China and 100 in India. Chinese universities readily provided aggregated data, but not detail. Some Indian universities shared comprehensive spreadsheets, but others claimed not to know how many engineering colleges were affiliated with their schools or lacked detail on graduation rates by major… What we learned was that no one was comparing apples to apples. In China, the word 'engineer' does not translate well into different dialects and has no standard definition. … A motor mechanic or a technician could be considered an engineer, for example. Also, the numbers included all degrees related to information technology and to specialized fields such as shipbuilding. It seems that any bachelor’s degree with 'engineering' in its title was included in the ministry’s statistics, regardless of the degree’s field or associated academic rigor.”

Read the full article.

On SLAs

Successful business always starts with defining expectations.
You need to clearly communicate what you want.

Service level agreements (SLAs) are a helpful tool in dealing with an outsourcing vendor for several reasons:

• To help you clearly define on paper the minimum level of service that needs to be provided to keep you satisfied


• To define the critiria by which your outsourcer’s performance will be measured.

More often then not the vendors are not quite sure if they are supposed to run a marathon, or a triathlon, or perhaps just stay on the StairMaster for a while till something happens. Some vendors never bother to define reasonable SLAs, because they need your money, and they are too scared to ask questions.

So it is up to you to realize that both parties need to actively participate in setting the right SLA metrics, and to do that the client’s goals need to be clearly communicated.

What is your main objective? Is it speedy time-to-market as cost-effectively as possible, and adding more business functions later? Or is it building a full product from the start? What factors could be sacrificed now in order to fully focus on the most important tasks?

SLAs don’t have to be complicated or so detailed that they are too costly to define.
But the basics need to be communicated and agreed upon so that both parties are on the same track and provider’s service can be properly measured as adequate or inadequate.

When defining SLAs, try to avoid ambiguous language. Statements like "All support tickets will be responded to in a timely manner" don’t mean anything unless you specify what "timely manner" is. Instead, you should say: "All support tickets will be responded to within 48 hours". That way, if a vendor hasn’t responded to a support ticket that you posted 3 days ago, you both can clearly see that your vendor performance is "bad". At the same time, if another very important issue arises, your vendor can address it today, and respond to your ticket tomorrow, and it will still be "in a timely manner".

Did you enjoy this post? Bookmark to del.icio.us

Outsourcing: How Much Do You Really Save?

Businesses spend billions of dollars on IT outsourcing for obvious reasons:

• To lower the cost of IT development and maintenance;


• To improve service and free up internal IT stuff for more strategic work;


• To raise the skill level of internal IT staff thru the transfer of knowledge from outsourcing providers;


• To free up in-house staff from IT services and focus on the core business competencies.

According to analyst firm Aberdeen Group, reducing IT costs remains the main driver behind outsourcing for 82% of companies in the US that engage vendors in developing countries.

But how much do you really save when you outsource?
Surprisingly, companies report only a 26% average cost savings on outsourced projects, with nearly half of outsourcing projects failing outright, or failing to meet expectations.

According to Aberdeen:

• 76% of companies said that vendor management effort and costs were much higher than expected.


• 30% reported ongoing issues with outsourcer management processes (e.g., inadequate governance and conflict resolution procedures).


• 51% reported that outsourcer was not performing to expectations.

What are the main barriers that reduce the success of outsourcing down to such numbers?

A lot of companies fail to recognize that $25/hour in India versus $100/hour in the US for IT development work doesn’t simply translate into a linear 75% cost reduction for the overall project. Since a successful project goes beyond writing code that compiles, it has to include a set of other important factors and processes that have to be managed, at least partially, in the US:

• Thorough understanding of your business, your competitors’ strategies and your industry in general.


• Proper communication of your business goals. Is it speedy and cost-effective time-to-market and adding more functionality later? Or is it building a full-functioning product from the start? What functions are less relevant and could be sacrificed now in order to get the best value for your dollar?


• Properly set service level agreements that clearly define expectations and responsibilities


• Detailed Discovery phase and proper documentation throughout the project


• High commitment on the home front to keep the strategy and processes on track

In many cases a special set of management skills is needed, since the development team is located abroad and is out of your sight. Apparently the “out of sight – out of mind” approach doesn't work too well.