How to select a software vendor?

Let's face it, selecting a software vendor is not easy. There are just too many out there and it's very much like what you feel when you are looking at many brands of vaguely similar products in the supermarket and trying to decide which one to pick up! Today, I'll try go over some of some of the things we feel that you should consider before picking up your vendor.

When you select a software vendor or software developer, you don’t just commit to a piece of compiled code. You’re committing to a way of doing business. That software – if it’s the right tool for the job – could be something you and your employees use regularly for years. And if turns out to be a square peg in a round hole, you’re SOL, back to square one, repeating the same software search you thought you just finished.

With so much riding on your selection, how the heck do you do it right? How do you find that magical software vendor, custom development team, or SaaS provider that works for you?

Evaluate the Product

Almost everybody starts their vendor search by shooting a swarm of RFPs into the void and hoping that helps narrow things down. The problem with RFPs is that nobody wants to tell you that they can’t do something. Once your RFP process weeds out the folks who aren’t ready for your jelly, you can start actually finding out what solution will work.

At this stage, you should get some hands on time with their product or, if you’re scouting custom development, their previous products. Sit through a demo, then see if you can get your hands on a trial version or run a smaller project with them first.

Pick software like you’re Goldilocks: not too slim, not too robust. You want the feature set that’s just right. Plus, you’ll see how stable their work is, and avoid critical crashes during crunch time.

Evaluate the People

You aren’t just buying a software solution, you’re getting a vendor and all the people therein. Find out what their company culture looks like. This might be the single most important factor of all. You need a vendor that shares your vision of the business landscape. Do they operate on the same time schedules that you do? If your business runs an Agile shop dropping weekly updates, imagine how much of a hassle it’d be if your vendor only updates yearly.

The people you work with should be responsive enough to take care of your issue before they cost you money. Whether that’s support issues, implementation work, or feature requests, how your vendor communicates with you can make or break a relationship. And make no mistake, this is a relationship, so chemistry matters as much in business as it does in romance.

Evaluate the Partnership

Your software vendor will become pretty integral in your business operations, so you want to make sure they operate as your partner, not just as the guy who sold you something. Are they excited about your project? If you’re looking at an implementation or custom development process, this is incredibly important. Your vendor will play midwife to your product concept, so they should care about it enough not to drop your baby.

Make sure the pricing scheme they offer works for you. That might mean exploring alternate pricing structures – fixed price, hourly with or without a cap, monthly fees, etc. It’s in both your interests to set a price that works for everybody. Your success and your vendor’s success are linked; if one of you goes out of business, the other one gets hurt as well.

Choosing a vendor should be more than just ticking off features on a checklist. You need to review the whole partnership, including the people you’ll work with and the partner you’ll have. Remember, we succeed together and fail alone.

Oh, one last thing, consider us when you are searching for developers who will build your next great app. We are a small award winning software development company solely focused on helping our clients design and build their software products. 

5 things every software development contract should have

Software projects are different from many other projects where a physical product is built. And hence there are some issues that a software development contract should address that are not very common is other contracts. Yes, like other contracts there would the usual suspects like commitments, warranties, liability, etc. But here are five not so common ones that our experience says are essential for a software contract.

1. Initiation Period

This allows both sides to disengage easily for a limited period of time after the start. This is essential because only when a project is started does it become apparent if the relationship is a workable one. A great software company with perfect skill set, gold plated credentials may turn out to be very bad at communicating ,for example. Similarly for a software company it may turn out that the client just can't agree on technology choices. Whatever it is, if there is no fit the project will fail or the process will be painful. This lack of fit becomes quite obvious very quickly. So the contract needs to take this risk into account.

Here is clause we commonly have in our contracts to cover for this initial period:

"The Parties agree that they shall commence the engagement with an initiation phase of six calendar weeks, commencing on the Effective Date of December 1, 3001. Acme inc. will provide services during the initiation phase, and BigShot inc. shall be liable for payment for such services. During the initiation phase, this agreement may be terminated with one calendar week’s notice; at the end of the initiation phase, the agreement shall enter into ..."

2. Change Requests

A software product is a moving target. You can have the world's best specification when you start but you'll end up with a software that is slightly different when you finish. This is normal. This is the way it should be. Because as the software interfaces are being built new requirements arise or old requirements change or die out. If development stays rigid and doesn't listen to these change requests the resulting software will not be good. So "embrace change" is the way to go. But, how do you setup a contract to cover this risk?

There is no single answer that fits all size. How you address this in the contract depends very much on the project. If the specification, for a project, is very good and detailed a wording that allows a certain percentage of change may work nice.  Here is an example:

... up to and including between 5 and 10% changes in any Work Product, order, and other goods and services that Acme inc. produces or designs under this Agreement at no additional cost... 

If the spec is not that clear then the above wording would be disastrous! Here is an example that just might work in those cases (this is what we have used in some projects):

 "...If the proposed change will, in the Developer's reasonable opinion, require a delay in the delivery of the Software or result in additional expense, then the Customer and the Developer shall confer to first determine whether the request is a Change Request or an Additional Feature Request. Where it is agreed that the request is a Change Request, the Customer may in that case elect to either
(a)    Withdraw its proposed change, or
(b)    Require the Developer to deliver the Software with the proposed change, subject to the delay or additional expense or both..."

3.  Software IP

This is an obvious one. So I won't spend time on this, but just mention something that sometimes is missed or not considered. In many projects the software developer might use a library or a component that it has built as a re-usable tool to be used over and over on client projects. The IP for such components belong to the developer but the contract wording should allow the customer to use it royalty free. Here is template that works nicely:

"...To the extent that developer uses any developer IP when providing Work Product for customer under this Agreement, developer grants customer a perpetual, irrevocable, royalty-free, non-exclusive license to perform, display, use, reproduce, modify, and adapt the developer IP, in any medium or form of communication now existing or hereafter developed, within the Work Product..."

4. Non-Competition

An inherent risk of employing a software development company to develop software is that they might also be hired in the future by a competitor or even worse make the software themselves. The contract needs to address this risk clearly with a non-competition wording somewhere. Here is an example:

 "..for a period of x years after the termination of this contract the developer shall not develop, reproduce, promote, distribute, market, license or sell any product or service that competes directly with the Work Product provided to customer, nor shall the developer enable any third party to compete directly with customer..."

5. Hiring Resources

The team that builds the software becomes experts of the system. If the software project becomes very successful the customer may want to retain certain members of the team. The software development company would obviously be worried about this. So this need to be clarified right from the beginning in the contract. Software resources are precious, so this is a delicate situation and finding the right balance is difficult. Here is a wording that is pretty fair:

"...customer may request developer to place named team members as direct customer employees, with the express prior written consent of developer. Developer shall be entitled to compensation for placement of such employees; the relevant compensation shall be discussed and agreed prior to any discussion of such placement with the employees concerned..." 

Disclaimer: I am not a lawyer. You should always seek professional legal advice when you are setting up a contract. 

As usual, I'll finish with a stolen cartoon from Dilbert. But to give something small back, have you read Scott's book "How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life"? If you haven't you should. Really good stuff. 

Be careful techies, I'm Dutch!

How should Dutch software project leads manage and run their outsourced software development?

This was a question that came up when we published our recent article about how Dutch software project leads are different than others (and why those differences are good). In today's article I will try answering that question based on our experience in working in software projects from the Netherlands for more than a decade. 

Warn that you are Dutch (and you are direct)!

There is no denying it, you are likely to be perceived as difficult (or at best: different) when you use your natural directness. This perception can make things go wrong, and lead members of your offshore team start to think your sentiments as always negative. Software is all about collaboration and a perception like this will make collaborative work hard and result in a bad software.

Testimonial for Kaz Software from International Guidelines - an Amsterdam based software startup.

As I argued in that other article, this directness is really your asset in a software project - so don't even think about changing (or "adapting" as some people may say, stretching the agile philosophy too much). To address the risk of a negative perception all you have to do is remind your team at the beginning (and then time to time) that you are Dutch and the Dutch are known to be direct - they don't usually mince words. You will find that your software team actually appreciates this directness - once they understand that this is how you are from a cultural context. Any good software team understands very well the need for constructive criticism of their work. And once the fear of negative emotion is gone it will make things simple. It has always been that way with all of our projects.  

Beware of deadly high PDI

PDI is power distance index. Which, in the context of software development, can be explained as a measure of:

How unlikely is a junior programmer to tell a senior team member when he spots an obvious error in the latter's code?

High PDI means team members stay silent and don't speak up their concerns. PDI varies by nations. And it has been shown (and you really don't need data for this, you can feel it) that countries in South and South East Asia have high PDI. Which translates to the fact that your developers are less likely to speak out against you even if they know you are wrong. Check out our article about the risk of PDI in software projects.

This becomes an acute issue when you mix a Dutch person as the project lead/owner/client and an outsourcing team in a high PDI country. The Dutch person speaks out with directness that is her natural instinct, the high PDI "stricken" developers start to take her words as the law - so there is no debate, no arguments. A software cannot be made without debate (and we say even fights) - and the situation above removes those essential debates leading to bad design, bad technical decisions and thus bad software.

So what can you do? Difficult to answer this. You can of course hire a company who has a culture of speaking out (and thus low PDI), for example us (ahem!). Kaz Software does a lot of things to keep the PDI low (check out our article about this: Killing PDI ), and so does many other companies who recognize this threat. The other option is to create this awareness yourself within the team, particularly the team lead or the interface person. If the external team lead understands this she can then mitigate the risk within the team.

Insist on visibility of day to day workflows

This is important in any outsourced software project, but particularly so if you are Dutch. This visibility will give you data to act on, take corrective steps on a much granular level. This would reduce a lot of friction that are likely to happen if you see results after long periods.

Insist on making the task management/issue tracker available to you online. You should be a user in the system and be able to add/modify/comment just like any other team members.

There must be (as with any project) a build system that lets you build and use the software at its current state. A dev and a QA server should let you see and use the software at any time. And you should set aside dedicated time to play with the software regularly (ideally daily) and give feedback on what you see. This is a basic agile step, but also an important step to prevent friction.

If you have software people on your side, the code repository should be regularly used to compile the application being built independent of the build system that the dev team has. This will let you identify technical issues early in the process. 

A weekly call is a must for any software project, but consider daily calls too if you can keep them short (otherwise they become detrimental to the workflow).

Break the ice

I've saved the easiest and the best for the last. Most of the time all you have to do is just create a good relationship with the team. If you can break the ice, everything else becomes that much easier to do.

If your budget permits visit the team, do some activity away from work together. Even a trip to the local food street and just hanging out with the team will do wonders. If a trip out is not possible then consider doing a video conference together with team and make it a non-work thing. It could be a simple introductions and sharing of stories. Tell a funny story, joke a bit and the rest becomes easy.

Distance makes human relationships seem rigid and artificial. Add to that the cultural difference and your infamous directness, things can seem very non-human-like. Break the ice, humanize the endeavor and you'll see that things are much simpler than it seems.

Before I leave: we are doing an ebook: "Guide to happy software outsourcing" where we will summarize all the little tips that we have been writing about. Leave your email address with us and we will email you when it's ready.

5 things software entrepreneurs must remember

Having a great software idea in your head and a fast moving software team to make that idea a reality is what it must be like to be on drugs. It’s addictive, it makes you stay high and there is nothing in this world that you can quite see with pessimism. This is what makes software entrepreneurship so attractive, this is what makes thousands maybe even millions give up their jobs and jump into this unknown, knowing all the risks and odds.

But beyond all the known risks there is an enemy that is always lurking– and very few people recognize it. If not recognized this enemy can kill.

The enemy is within. It is your enthusiasm! Yes, the very thing that makes the start-up successful, the experience amazing and that fosters innovation can also if not kept in check destroy everything.

Kaz, as a software development consultancy, that works with early stage start-ups and their highly driven owners and leaders, we’ve seen that enemy many times. And we have helped our clients tame this enemy and use it in right direction for the right causes.

Today I will list the top 5 reminders we give to our clients - to keep that enemy in control.

 

1. Remember that the app will solve only one thing.

In the mind of the owner the original idea of the software evolves and starts to become something that can solve anything. Maybe it can, but time and money both are limited. And the urge to add yet another feature to cover yet another use case can derail the software building process and eventually delay things enough to make the app fail.

The only way to keep things in control is to remember that however great the app, it will probably solve only one human pain – that is the most important use case and everything else can be discarded. The focus should be only that single use case, and release with that use case.

We sometimes suggest our clients to have the use case put into a single sentence, print it out and paste it in front of them somewhere visible.

2. Remember to compromise

A piece of software is all about compromise. You have to compromise on features, bugs that need to be fixed, delays you have to accept – the list is endless. By knowing when to compromise and on what, you make development process smooth and meet the deadlines. And most importantly for early stage startups get the release up where people can start using it.

For entrepreneurs, their idea and thus the software is like their own child. This makes it very difficult to compromise. In some cases, we’ve found, they forget that it is good to compromise. They start treating compromise as something evil. And this has huge negative impact on delivery schedules.

Remembering to compromise is something that makes the difference between a software out on production box and a software in an endless loop of fine-tuning in the dev box.

 3. Remember to trust others

Software requires collaboration. A single person cannot get everything done to get a software from ideas to reality. And collaboration implicitly requires trust.

Normally a software group can easily create trust amongst its members (obviously things can go wrong, but that’s because of some real problem in the team). But in a start-up scenario, especially in its early stages, sometimes the owner can find it difficult to form that trust relationship with her developers. The cause, I think, is because of the constant feedback she gets from the team about the time it might take get certain cherished features done, etc. As harbinger of bad news, typically the team lead may seem to be the person who always dampens the spirit. This can sometimes make the owners difficult to trust the lead or the team. And if that happens everything suffers.

Teaching herself to trust can be one of the best things that an entrepreneur can do to help the team. When we face circumstances like this, we try communicating this in various ways. Not being Dutch and not having the wonderful ability to say things directly makes it difficult for us! But our way out is to do it in little steps and also to involve the owner more with the actual development process so that she can understand things better.

 

4. Remember that the software is for others.

This one is the hardest to remember. The entrepreneur lives with the idea and process of software building with such focus that, we find sometimes, she forgets that the software she is building is actually for someone else – users! Remembering this important, knowing what your first customers are like and that the fact they might have completely different persona and requirements than you keeps the feature planning and decisions on track. What you may value as important may not be what your average users would value so much.

We suggest doing a regular thought exercise where a question starts with “When user Mr. X uses this feature…” to our customers. This sets the context and understanding that the software need to be viewed through the eyes of a typical users. Our interaction designers are big on Alan Cooper’s user persona creation process and we have found that including the owner with that process helps immensely to disassociate herself from the target software users.

5. Remember that there is a tomorrow.

Owners sometime forget that software has the possibility of versions. What we cannot achieve in this version can easily be added to the next version. Splitting up the features into versions and phases is the essential software project management activity.

Sometimes it’s hard to push cherished features in the back-log, and owners feel like that they have to cram everything in the next release. If the next release is the first one, this is most painfully felt. Remembering that there is a tomorrow that a new release can be done pretty soon – even really the next day can help a lot.

 

Are Dutch companies difficult to work with?

We sometimes get asked the question: "are Dutch companies difficult to work with?". We get asked probably because we have been working with companies in the Netherlands for more than a decade. There seems to be a perception (at least among software consultancies)  that they are "difficult" and I think I know why that perception exist. I'm going to argue today that the qualities that create that perception are exactly the qualities that every outsourcing software project owner should have to make that project a success. 

But first a disclaimer: it is always risky to generalize, and I'm no world expert on how the techies of a nation think (does that make me safe from some of those eggs and tomatoes ready to be thrown at me?). 

Here are the qualities that I find common in Dutch software project leadership:

Persistent concern for the state of the project

The project managers or the owners have an almost palpable feeling of concern that the project might be going in the wrong direction. This keeps them pinging back for regular status checks, keeps tech teams on their toes and there is usually a lot of communication. 

I think this is the single most important thing that EVERY software project owner should have, irrespective of the fact its an external team or an in-house team that is working on the project. If the team is external, and especially if the team is thousands of miles away this is probably the factor between a project that is failing and one that is successful. But note that this sometimes this might create an impression in the tech team that the leadership cannot fully trust their ability - so this has to managed well to keep the team productive.

No mincing of words- the directness

Dutch project leads don't shy away from saying negative things if they see it. Whereas in other cultures (including Bangladeshi, but most painfully in the English) there is a tendency to keep negative things unsaid. Not so with the Dutch, and this is just perfect in the context of software projects. You just cannot stay polite and hope that those bugs or those obvious missteps in the dev process will fix themselves. 

At Kaz this is something we try to code into our genes (check out the article about this: killing the deadly PDI) - to be direct, to say the negatives without worrying about how your colleagues would feel because this is the only way to make great software. It's incredibly lucky that with the Dutch project this valuable trait comes automatically.

Budget consciousness

Although it is obvious that every project leadership should be conscious about the budget, you'd be surprised how many stories there are about projects eating up the complete budget because the stakeholders get carried away with features or they just don't plan things well. Software projects are prone to go off track - estimates tend to be wrong, features tends to bloat, owners  love to get fixated about some use case that they must have yet no one uses.

Being budget conscious keeps the project on track. It lets everyone make informed decisions about where to compromise, what feature to prioritize and most importantly when to  stop. So having this in project leadership makes projects successful.

The proof of the pudding is in the eating as they say, and I can tell from Kaz Software's experience in working on Dutch software projects for the last eleven years that whatever it is, the Dutch certainly have a flair for successful software. We are proud to say that we've never had a project from the Netherlands that had failed!

 

Meet us.

We'll be in the Netherlands

22-26 November, 2016

If you are around and want us to meet you, to discuss a software project, please drop your email address below. 


Update: One of our customers in the Netherlands recently did a video about our work with them. Thought this is a perfect place to share that.

Nightmare in code street - a software project horror story with a happy ending

I recently came across a documentary, spaghetti code, that talks about how a multi-million Euro software outsourcing project became a disaster. The film was in Dutch but given the topic, which is the focus of most of my energy these days at work, I persevered to understand. And with the help of my Dutch friends got to the gist of the story, which is sadly a very common one – big company outsources software development to another big outsourcing company, there are many layers of management and not everyone is sure what is being done, the project fails and developers far away gets an unfair proportion of the blame (although to be fair, the documentary blames the management too and also there additional twists of greed and corruption).

I smiled and then raved a bit with righteous rage (being a techie in the inside meant the slur of “spaghetti code” and blaming it all on the developers touches a nerve or two). Then I cooled down and decided to write my “ultimate guide to safer outsourcing” or something along those lines. Which, by the way, is what I was planning anyway for my series on software project outsourcing – the first of which appeared last week: deciding whether to outsource or not? But a little more reflection led me to ask:

 Was I also not hiding behind righteous indignation and the comfort of the “blame them” myself? Weren’t there a story or two of my own where things went wrong?

Let’s face the facts; a software project is difficult to pull off smoothly even if the team is in-house. Add to that difficulty a team that is miles (sometimes thousands of miles) away, different culture, different language and different time-zone – you have a really risky venture. There are of course ways of managing that risk. They are time honored, field tested and pretty fool-proof – but they are to be the subject of a different article soon. Today, I’m going to face my nightmare and tell you the story of how everything went wrong in one of our projects, and (happily) how we survived and saved that project. I can’t go into too much details, of course, but will stick more to an overview and on what we learnt from the experience which I think will be of more value to my readers.

The project

It was an angel funded project trying out a very innovative solution for a common problem that happens in large companies. There were three people on the client’s side with none of them with any prior experience in software. They had an existing codebase – a left over from a different company that they had used and did not like.

The spec

We received a large amount of documents at varying degrees of up-to-dateness (and yes, that is an acceptable noun). Then we did several sessions of going through the concepts. We found that the clients have actually moved away from many of the features as described in the specs. This is something very common with start-up, actually it was surprising that they had specs at all, so we were not worried.

The process

We are an agile shop when it comes to process. For startups we choose a Kanban model, where pretty much everything thing can change at the last minute (within reason). This works best for start-ups because most of their priorities and product requirements move with time.

We chose trello for issue management, google docs for sharing documents, github for source control. We put a tried and tested scheme of weekly meetings and daily builds. Since we saw a lot of instability in the feature requirements, we added a short but daily feature discussion session with the clients and our designer and  project manager.

The nightmare

Almost from the start things started going wrong. We kept getting feedback that the product features were not what they were expected to be, this led to piling up of tasks that were adjustments to features we’ve already done. This backlog led to delays in delivery of major releases planned – which led to our clients losing important business. Something was very wrong, but we didn’t know what it was. We had put in all our standard safety measures in. We were communicating (maybe too much) on a daily basis. It just didn’t make sense.

The realization

After several missed deadlines and lost weekends (which we avoid the like the plague because it’s the worst thing you can do the developers’ productivity) we decided we need a proper retrospective. We pinned the problem down to the following:

1.       Clients could not visualize the features that were to be built based solely on the wireframes we were using. We had opted to do quick wireframes to speed up the process to meet the delivery schedules of the client (typical for start-ups that need to demo to prospective investors).

2.       The feature priority that the clients were setting was not taking into consideration the relative level of effort for the features. So we were not doing the good practice of picking up easy to do features first even though they might be slightly lower in priority than other harder features.

3.       Unrealistic expectation about deliveries, and correspondingly ambitious estimates from the team trying to appease those expectations.

The happy ending

We spent days thinking up of new and quite frankly convoluted fixes. But finally we boiled them all down to an absurdly simple solution – there needs to be a techie on our client’s side.

We managed to convince our clients (somehow, don’t ask me how!). They hired a consultant who would work with them 3 days a week in a role of a product manager. And things changed for the better almost immediately. The fix really felt like a miracle cure.

The moral of the story

… is that: there is no single formula for making your outsourced software project safe from disasters. There are prescribed best practices that you must follow, but stay alert for signs of failures and jump in with remedies when you see them.

Well that’s the horror story. You can never really depend upon a foolproof process in this world. But there is one thing you can certainly depend upon – there will always be an appropriate dilbert strip that you can steal, for anything to do with life in engineering. Here is my loot for today’s article.

5 points for deciding to outsource or not your app development

 

You have an idea for a great software or an absolute need to get an app done to boost your productivity, but you don’t have software developers. How do you make your app? Do you hire developers or outsource it to a bespoke software development company?

These questions are not easy to answer. From our experience in this space for more than a decade, here are the top 5 things to consider.

DO I HAVE THE DOUGH?

Do you have enough money to hire in-house developers and also spend on marketing?

If the answer is yes then it’s a strong reason not to outsource. We’ve got to be honest here, having your own developers working next to you is the best, if you can cover some of the other risks around this. But you should also consider, if it makes sense to get more mileage out of your funds by using a lower cost source or if you want to spend more on marketing, keeping the development cost in control.

CAN I MANAGE TECHIES?

Do you or your in-house team have experience managing a technical team?

If you answer yes then that’s perfect and you will need that experience whether you outsource or hire internally. But if you answer no, then that is a big reason for outsourcing your project. As anyone with experience in the software world will tell you, software project management is a pain (and also an art). With an outsourced project, if you choose the right partner, you can also outsource that pain to someone else! Set the milestones and your delivery expectations, reasonably, and it’s the job of an experienced project manager to get those expectation met.

HOW SPECIAL IS MY CONTRAPTION?

Is some unique algorithm or convoluted calculation the main business value of your application?

If you answer yes then this is a strong reason not to outsource, at least that part of the software which is unique. When you outsource you don’t have direct control over the resources and a developer who might have the whole algorithm figured out in her head might just leave and it’s very difficult for you to stop that. Also, business sense says that the knowledge should stay in your control. Google wouldn't be google if they outsourced their search logic!

The solution could be that you hire developers for the core and save money by outsourcing the the rest. Or you could have a contract which lets you have the option of hiring the resources at some point.  Here is something that we sometimes have in our contract to cover this situation:

“...Acme inc. may request Kaz Software to place named team members as direct Acme inc. employees, with the express prior written consent of Kaz Software...”

CAN I GET ALL THE SKILLS TOGETHER?

Does your in-house team have a variety of technical skills?

Software requires all sorts of skills. To start things off you need a variety of ideas in your brainstorming so that innovation can happen. Then you need designers to draw things. You need technical people to say what’s possible, what’s a good trade-off (“oh that will take years to support on Internet Explorer”) and you need them to write the code (of course!). Then you need testers to check if there are bugs and systems guys to find the right server to deploy and launch the product.

When you are using an in-house team, usually you have to get by making the same person to put on multiple hats. This may work but it limits the set of ideas and possibilities. When you outsource, you usually get a pool of resources from which people can be drawn into your team at the right time and then moved out. This is a big one for going the outsourcing route if your local team is small or non-existent.

HOW ROCKY IS THE ROAD AHEAD?

If you have a business plan and the market research that says things should be a sure shot then going in-house works. But if you are not sure and know that the road might be rocky ahead then having development outsourced is much safer - it lets you ramp up or ramp down fast. With an in-house team both growing and reducing fast is painful and expensive. And having a reputation of that instability makes it that much difficult to hire talented techies from the market.  

Worried? Don't be. At the end it's an adventure and if you play thing right a really good one. Contact us if you need our advice or want to consider us for developing your app. We have loads of experience helping customers like you. 

Offshore software development in Bangladesh

Today I will make a case for outsourcing software projects to Bangladesh.

The new offshoring destination in the block

Bangladesh is fast becoming a major player in software development outsourcing. The volume of software projects offshored here has doubled almost every year for the last couple of years. More than twenty thousand people are now working in software or IT services industry. The software industry in Bangladesh is mainly involved with exporting services like custom software development, SQA, design and graphics to European and North American markets.

Micro offshoring revolution! 

Separate to this formal sector, a huge informal sector of Bangladeshi freelancers are driving a micro-sourcing and micro offshoring revolution! Bangladesh consistently tops the freelance work location on sites like oDesk, eLance. This is really an amazing phenomenon, driven mostly by teenagers

Average cost of a 25 people software project.   Source: KPMG study

Average cost of a 25 people software project. 

Source: KPMG study

Bottomless resource pool

Bangladesh is the 8th most populous country in the world. There is a huge supply of young, trained and English speaking (English being taught from day one at our schools - a side effect of being an ex-British colony) resources. The total cost operation for a typical software offshoring operation is almost 40% lower than countries like India or Philippines. Apart from resource costs other costs like infrastructure, support and management the price advantage with competing outsourcing destinations is significant. Cost of living in India for example is fast becoming comparable with countries like Malaysia or Thailand and thus the future of outsourcing advantage to India is decreasing every year.

This is where Bangladesh outshines others - with very similar educational standards, Bangladeshi resource pool is not fully tapped and its potential to become a major software outsourcing destination is exactly like India of the 90's. A recent KPMG study is a very good read to get an idea about this. 

Maturity of the industry

Software organizations are also becoming mature and standardized. Companies like us that has been doing software development outsourcing from Bangladesh since 2004 have gained huge experience over time. The wide range of projects that we (and other companies around us) have done exposed our developers, testers and mangers to the challenges of software development process. This has created a strong base of experienced, mature and skilled resource who in turn mentors new comers in the profession. A lot of our alumnus has formed separate companies of their own to do offshored software projects, and have carried on the maturity and experience into new areas of works. This migration has also had an effect of evolution on the culture of workplace and software creativity that Kaz values.

More such companies are being setup with proper development  process and management required for outsourcing needs. The creative culture for software development of such organizations are also noteworthy.

We look forward to a great future in software outsourcing in Bangladesh.

 

N.B. Just in case you are new here: we are a custom software company  in Bangladesh making custom web, desktop and mobile apps for other companies and being very good at it! Check out this page to know more about our software development work culture and environment.