RSS
 

Outsourcing: A False Economy?

17 May

It comes as no surprise to any of us that the offshoring of software development and testing efforts has become the standard for most companies. But what drives that decision, and how does a company determine if it is the right choice for them? Once a company has been outsourcing for a while, what steps can help them to determine if it is working in their best interests?

When I joined my current company, we had a development and quality assurance (QA) office in India. To the money people, this sounded like a smart idea since the staff salaries in emerging markets can be quite low. While I had my own experiences to draw upon that told me this was a risky strategy, I only had subjective evidence that it wasn’t the best option for this company. Subjective arguments don’t go very far with the people who are managing the costs of a company.

In order to do an objective, fact-based review of the offshoring strategy for my company, the Director of Development (himself a big fan of outsourcing) and I put in place an Agile SCRUM development environment and tools that showed what people were working on, how much time is was taking them, and how many bugs were raised against their code. This system was used by the software developers and testers both onshore and offshore, and after a year the statistics were available to enable us to make an educated analysis of the success of our offshoring strategy.

Understanding the Challenges

The first step I took when performing the review after a year of offshore analysis was to identify the efficiency issues that existed due to the remote teams. The employees we had working for us in India were absolutely love people and tried very hard, but it became apparent that with their remote location there were challenges that no amount of dedication and good intentions could overcome.

Challenges:

  • High Staff Turnover – In emerging markets, the fast-growing job market means that as staff are trained on new technologies, they can use those new skills to get a higher-paying job in another company. The trend in many offshoring centres such as India is a new title being awarded each year, and employees generally leaving their company after three years (on average) to pursue a new role. What this means for a company is that there is a risk to training up employees or in relying on offshore engineers for long-term specialist knowledge. Essentially it becomes a risk to train your teams to perform the work you need them to do.
  • Remote teams make reactive testing difficult – For offshore testing of projects that are developed onshore, there becomes a need for detailed test plans to be written covering every feature, environment and user scenario. The training of the testers becomes an additional burden as does the management of priority of testing efforts and recognising what has been tested and what hasn’t.
  • Agile development requires geographically close teams - ?With Agile development, the potential for faster turnaround of higher quality code can be achieved, but only with highly integrated development and test teams. ?The personalities that can make Agile work must be highly independent developers and testers who do not need complete documentation prior to doing their work. With the requirement for detailed documentation for making offshoring work, there is an immediate roadblock to making Agile work.

Understanding the Team

In a report titled “Rebalancing Your Organization’s Agility and Discipline” [PDF] by  Barry Boehm and Richard Turner, there is an efficiency grading metric that helps to identify how adaptable team members will be to an Agile environment. The Manager making these decisions needs to take the time to get to know the developers and testers as well as becoming very familiar with the work performed by each employee.

Table 2. Levels of Software Method Understanding and Use

Level Characteristics
3 Able to revise a method (break its rules) to fit an unprecedented new situation
2 Able to tailor a method to fit a precedented new situation
1A With training, able to perform discretionary method steps (e.g., sizing stories to fit increments, composing patterns, compound refactoring, complex COTS integration). With experience can become Level 2.
1B With training, able to perform procedural method steps (e.g. coding a simple method, simple refactoring, following coding standards and CM procedures, running tests). With experience can master some Level 1A skills.
-1 May have technical skills, but unable or unwilling to collaborate or follow shared methods.

(copied from “Rebalancing Your Organization’s Agility and Discipline” [PDF] by  Barry Boehm and Richard Turner)

After getting to know my team and the work they each performed, I was able to apply these efficiency levels to each of them. The team members working onshore were mostly level 3 with a few level 2s which menat that they were able to work independently and without strict direction whereas the offshore team was averaging around a level 1B or -1 which required a bit more direct management.

Cost of Doing Business Overseas

The next step in determining if offshoring is costing the company more than the savings in salary costs is to identify the additional costs of doing business overseas. In order to make an offshoring strategy successful, a company needs to send the highly-skilled onshore engineers and testers with specialist domain knowledge down to teh offshore location for training at least twice a year. Reviewing the travel costs as well as the cost of these specialised team members not performing their own work is critical. Next, an onshore and an offshore manager need to manage the relationships, ensure that the necessary documentation is being written, the training requirements are understood and addressed, and the knowledge transfers are taking place. Other costs to review are redundant systems such as hardware for test labs, automation testing equipment, software licenses, and test suites. Finally, calculate the amount of time that the onshore team members lose from their own work by needing to mentor the offshore team. This mentoring overhead usually requires between 10% – 20% of the onshore and offshore team’s time which can become quite expensive.

The argument for offshoring almost always stems from teh argument that salaries are lower in the emerging markets, however the rapidly increasing job markets in these offshore hubs are driving the salaries higher at an alarming rate. Many companies have been transitioning their offshore efforts from India to China, but according to GIS Jobs Survey 2010 and Hayes Salary Guide 2010 the costs of doing business in China are on par with doing business in India.

Making the Tough Decisions

After a year of looking at this question objectively, my company came to the conclusion that the practice of offshoring our development and testing efforts were costing us for more than we were saving. We made the controversial decision to close down our India office and spend the measurable costs on hiring fewer developers and testers into our onshore location. This decision was taken over a year ago now, we’ve had the team working in our UK office for one year, and the difference in our products has been truly spectacular. Our developers and quality assurance engineers work very well together as a team, they respond to customer requests quickly, and the feedback we are getting on our products from the past year has been very exciting. We are now creating really ground-breaking products with very fast turnaround, rapid adoption of new technologies, lower support costs due to improved testing and usability, and higher sales due to very satisfied customers.

Share
 

What drives your software company?

07 Jun

In my many years working with software development companies, I’ve seen three distinct types of leadership, each with its own challenges. The leadership tends to evolve along a consistent path within each company, and some companies survive these transitions while others don’t.

Most software companies start out as a technology-driven company. This means that a few brilliant engineers got together and created a cool product. Quite often when this happens, there is excitement around the technologies within the tech world, a round of investment will be raised, and a few sales are made. The management team, usually made up of the founding engineers, ramp up the employee base, create more and more cool products, and hope they sell enough to cover the company costs. Generally the headcount will rise to between 100 – 300 employees, there will be one large customer not-quite-covering the development costs of each product (if they’re lucky), and fixes to products are performed and delivered to customers quickly. As the company grows, however, it soon becomes obvious that there are more products than customers and the overhead on those products ends up being quite high as there are customisations unique to each customer that need to be maintained in separate code braches. The customers become more demanding without a willingness to pay suitable maintenance costs to cover the cost of developing the customised product.

Many of these companies will be taken over by new leadership in the form of a new CEO, new board members, and maybe a few new management team members. The board of directors will be becoming impatient at this point for higher revenues, so often the new CEO will have a strong sales background. The company will now suddenly be a sales-led organisation. The new management team will want to go through a cost-cutting exercise to please the investors as well as generate as much revenue, quarter-on-quarter, as possible without as much of a long-term strategic focus. They will talk about long term strategy because this is what they strive for, but the focus on short-term revenue will pull the development teams from product to product in order to deliver whatever it is that the sales team has promised the customer. There will be initial discussions around reducing the number of products being developed, but the fear of saying no to any customer, no matter how low revenue the deal is, will mean that the product lines will stay alive and continue to be developed according to what the customer asks for. The development teams will be pulled off of a product midway through the development cycle to respond quickly to a customer request, and long-term strategic projects will flounder while short-term requests are met. Many key developers will leave the company at this point because the excitement of creating something new and innovative has been lost. The sales team will make deals based on revenue rather than on profits, and there will be a consistent quarterly panic to meet the revenue targets even when each deal will cost the company more to develop than they will recognise in revenue.

With any luck, the companies will last until they evolve into a market-driven organisation. This type of organisation tends to have a much longer strategic outlook. There will be fear among the staff of more processes, but processes, when done right, are generally made to make things easier and more stable. Unlike the sales-led organisation, the goal here is to create fewer products and sell them to many customers. To do this, there needs to be strong product management. The product manager needs to own the product rather than letting the sales team or development team own it. neither of those other teams will like to hear this because they had been in charge for so long, it will be uncomfortable for them to not be making the decisions any longer.

The first step is to review the product lines within the company. Break them out into cash cows, future star products, and those products that are struggling to cover their costs. Next, map out the strengths and weaknesses of the technologies, the staff, and the products. Finally, do the same for the competition. The next step is to analyse the market to identify the problems that people are experiencing in the area where your technologies exist. Identify the market problems, and you will see an opportunity to solve those problems with the technical expertise within your company. This will require travel, so the travel budget needs to be opened up a bit despite the fear of spending money that the company will be experiencing right now. The product managers will need to go to industry trade shows to see what is happening in the market, meet analysts in the area, and network with existing or potential customers. Immediate follow-up with potential customers with a request to visit them not on a sales mission but on a potential partnership mission is imperative. Once you understand the market, the problems in the market, the trends people are talking about, and the customer problems, you can go back to your team and develop a solution. Do not be afraid to ‘End of Life’ a product! If the products are not valuable enough to customers, then they are not valuable enough for you to continue investing in them at the cost of more sellable products.

The key is to make sure that the solution solves real problems for as many customers as possible, thereby generating repeatable long-term revenue while keeping costs low and developers happy. Your investors will thank you.

Share
 

Ten Years Later

15 Dec

Tonight marks the 10 year anniversary of the car accident near my home in Los Angeles that changed my life, and the 9 year anniversary of the second accident. After losing everything because of my injuries, being disabled for four years, being fired from my job for being disabled (thanks to a loophole), losing my self esteem and my figure, and hitting rock bottom, I succumbed to the urge to run away from the very systems that failed to support me such as the legal system, health insurance, doctors, etc. and bought a one-way ticket to Europe.

That running away was the greatest thing that could have happened. Despite almost chronic pain because of the accidents, I am living the European life I had only dreamed of. So thank you to that ridiculous housewife in her SUV that ran a red light that day and to that idiot dude in his Chevy Suburban who hit me on the other side a year later. Neither of you ever knew the horrible things that your carelessness caused, but neither will you ever know the wonderful outcome.

Share
 
2 Comments

Posted in Travels

 

Write Once, Print Often

27 Oct

A wise man once taught me that there is no need to write and rewrite and write again the marketing collateral for websites, brochures, and flyers for a product. In fact, consistency across marketing collateral goes a very long way towards communicating complex product descriptions and value propositions to customers, market analysts and sales teams.

I had first experienced the impact of writing canonical text in 2006 when I was working for a highly-technical company and was trying to find ways to communicate clearly what the different products did, how they related to each other, and why they would solve the customers’ problems.

The first thing that stood out when we began to review our collateral was that there was an awful lot of text on every webpage, brochure and flyer. And the text on each of these items was completely different from the others. This meant that the marketing teams were rewriting the text for every piece of marketing material relating to each product. It confused the sales teams and market analysts, and it certainly confused our customers.

The leader of our marketing department decided to have us write canonical text for every product in our division. He had us begin by writing a problem statement for each product (see my previous post titled “What is your Problem?”. The problem statement helped to clarify the basic value proposition of the product.

Because the problem statement included a list of features and benefits, an elevator pitch for each product became much easier to put together. This is a description of the product that you could tell someone during an elevator ride. For some products, this is a remarkable difficult achievement!

As pieces of sales collateral needed to be written with more detail, such as flyers, brochures, and seminar slidesets, the canonical text proved to be a very good starting point. Each piece of material that was written with more detail could be tailored to the audience, whether it needed to be more technical for seminars or at a laymen’s level like websites and flyers. This helped to ensure the message was consistent across audiences.

We then proceeded to expand this text into a website where we needed images – in this case screenshots. As part of the canonical text exercise, we chose a very small number of screenshots, graphs and graphics that would be relevant, interesting, and easy to reuse. Like the canonical text, these images were the same across all of the marketing collateral for each product. Make certain to save them as high-resolution the first time as recreating them for printed brochures is not fun.

By finessing all of the marketing material in the department in this way, we found that we were able to respond much more quickly to marketing needs, we were much more confident in our external communication, and our sales department and customers finally understood what we were talking about. Well, most of the time.

Share
 

What is your problem?

20 Oct

The other day my husband and I were in the middle of a long drive when we started discussing one of his business ideas. When described verbally, it was one of those ideas that was very complex and difficult to explain. We started thinking about how to simplify the explanation of the business model enough that people hearing about it would not get overwhelmed.

This was the perfect scenario for a problem statement.

For anyone who doesn’t know what a problem statement is, it is the basic problem that the market is experiencing which you feel you can solve with a product.

Writing a problem statement is not an easy task. I have found that it works best as a very simple statement without caveats or descriptions.

Good Problem Statement: “Traffic into Cambridge can come to a standstill, usually in the mornings.”

When I ask someone to write a problem statement, they invariably try to use their solution as the problem.

Bad Problem Statement: “Cambridge needs to create a congestion zone and charge drivers for driving within that zone.”

By using their solution as the problem statement, they have not only avoided acknowledging the actual problem they are trying to solve, but they have essentially ended any discussion around how to solve the core problem. If the audience doesn’t agree with their solution, there is no empathy remaining around the need to solve the problem that still remains.

Using Google as an example, chances are that the makers of Google didn’t sit down and say “lets build a search engine” just for fun. They probably first identified a problem in the market such as “finding anything on the web is difficult.” Their solution was “build a search engine.”

Now that the problem statement and solution statement have been sorted out, it is a good time to begin listing the features and benefits of your solution. This is another situation where people often mistake one concept for another. Your feature is not inherently a benefit, and the benefits that your solution provides don’t count as features.

I prefer to list the features and benefits in table format with features in the left column and benefits in the right column, each benefit aligned with a specific feature. The hypothetical Google features and benefits might read:

Problem: “Finding anything on the web is difficult.”

Solution: “Build a search engine.”

Feature #1: Robots scour the internet for words and phrases
Benefit: Website owners do not need to submit their sites for inclusion into search results
Benefit: The latest versions of website are always searchable

Feature #2: Words and phrases on the internet are indexed into a database of results
Benefit: Searches can occur fast and results displayed almost immediately

If you take this example and use it as a template, keep an eye on how often you find yourself writing a solution in the problem field or a benefit in the features field. After a bit of practice, you can get your product idea clearly defined and communicated.

Share
 

It’s Not About the Features

02 Oct

Something that many companies miss is that the success of a piece of software is not necessarily based on the features, nor is the success of hardware based on the technology inside. Instead, it is most often the pleasure of using software on a computer or devil e that drives adoption and leads to a product’s success.

How many users do you know who say “I love my HTC TytnII mobile phone. It has an ARM CPU in it which can be very powerful.” Outside of ARM’s employee base, I would wager that this sentence has never been uttered. When asked about how they like their Tytn, I’ve heard people respond with “it is too difficult to find what I am looking for” or “It is slow”. Similarly, the Nokia phones have traditionally been the market leaders in Europe, but time and again, despite the leading edge technology inside, the thing people focus on the most is the difficult user interface which often requires 8 clicks to do something that could only require two clicks.

There have been many astounding advances in hardware technology that should have made our devices such as televisions, mobile phones and laptops snowball into futuristic gadgets, but there is a chasm between the hardware technologies in a device and the software being written to exploit all this power. One example is graphics processing units (GPU). For years, high-end computers have had GPUs in their systems for driving video games and mathematical rendering, but now GPUs are entering the embedded space.

About this, users don’t care.

Where this gets interesting, though, is when software developers are trained on the programming languages specific to the GPUs and can really take advantage of the speed and power provided to them.

Still, users don’t care.

It is only when the user interface designers, software developers, and product managers work together that any of this becomes remotely relevant to the end users.

As an example, look at my favourite subjects, the iPad and the iPhone. Why do people love these devices? It isn’t because of the incredibly powerful CPUs in sided. It isn’t the GPUs inside. And it isn’t even the features. The users love these devices because the experience of using them is fun.

There is an emotional reaction to using these products that spans generations, cultures and lifestyles. Part of generating an emotional response is to be responsive and reactive enough that the excitement level doesn’t dissipate (no slow rendering). Another aspect of an emotional attachment is safety or absence of fear (the user cant break anything).

The users don’t care about the guts of the machine. They don’t care that the software developers wrote the graphics rendering code in OpenGL ES or DirectX to take advantage of the GPU. They don’t even care if you loaded the hardware or software with features or left everything simple.

The users care about the experience.

Share
 

Simplicity in Software is the Future

25 Aug

Yesterday I had lunch with a 3 year old (as well as various other adults) and pulled out the trusty iPad to help with entertainment and distraction. This might make you cringe at the thought of a sticky, fidgety little munchkin defacing such a gorgeous piece of electronics, but I had my trusty rubberised (washable) case on the iPad which has proven invaluable in the past when contending with my unimpressive gracefulness.

What struck me, though, was the speed with which the three year old was able to figure out how to interact with the iPad. That in itself was astounding, but even more remarkable than that was the ease that the child had in using the various applications that were presented to him.

I had previously downloaded apps such as My First Words, Insects HD, Bubbles, and iFish Pond to inspire children of friends of mine, and they are simple but interactive apps that engage a child’s mind. The key elements that make these apps worth paying for are the simplicity of them, the obvious purpose of them from the moment they are opened, and the inability for the user to do anything wrong within the application.

In this age of small, simple component software rather than the complex, behemoth applications of the 90s, this ease of use is going to become the element that makes or breaks a software product’s future. The days of a software application needing to be everything to everyone are fading fast.

These days more non-technical people are using computers than ever before. It is virtually impossible to get through daily life without a computer. Yet most software applications and operating systems still expect users to understand non-intuitive technical concepts in order to achieve simple objectives.

I believe that the key to success for a software company is to make things simple and easy, avoid adding too may features and options, and simplify. Apple has gotten it right once again, and if we are up to the challenge, the rest of the world can embrace the concept and make technology fun for everyone.

And here goes the remainder of your day:

Share
 
 

Games Review: Angry Birds

25 Aug

Hello, my name is Elan, and I am an Angry Birds addict.

* cue thousands of voices of other Angry Birds addicts saying “Hello Elan” *

Angry Birds HD, by Chillingo and available on iPhone and iPad, is a fairly simple game concept with a slightly disturbing sense of humour implemented in a clean, responsive manner.

The gameplay involves catapulting a variety of birds towards structures made up of various materials protecting evil green pigs that have stolen the birds’ eggs. Naturally, the birds are a bit annoyed with the pigs, hence the name. Each type of bird has different strengths against the different building materials used to house the evil pigs, bringing strategy to the game. Which bird do you use against glass, wood, cement, and even balloons? Fortunately the speed with which you can restart a game is so slick that you can try again and again until you’ve perfected your bird-launching strategy. Turn on the sound for a bit of silliness and to annoy the people around you for extra fun.

One thing that the creators of Angry Birds have done which keeps people like me (who have completed all levels a few times over) coming back for more is that they add about 45 new levels to the game for free on a regular basis. Not only that, but once you achieve three stars on every game in a level, you unlock bonus games called Golden Eggs. This is my current obsession.

The only thing that annoys me about this game is that techniques that I spend hours developing seem to come naturally to twelve year olds. They will inevitably pick up the game for the first time, try the hardest level, and use my well-formulated technique without me ever mentioning a thing about it.

Darned kids these days.

Share
 

Chasing the Sale = Chasing the Tail?

24 Aug

Anyone who has worked with me over the past few years will be familiar with my strong opinions regarding the importance of solid product management in a software development company.  I admit, when I first thought about going into marketing, I thought that marketing’s role was to support the sales campaigns. It took one specific product management course, Pragmatic Marketing, to enlighten me, and I’ve been a convert ever since.

If you read nothing else about product management, read the second half of page 5 in this presentation by Steve Johnson. It is a story we’re all familiar with, we occasionally need reminding of, and could make or break a company.

Basically, when you create software in your garage with your mates hoping to be the next Jobs/Wozniak or Gates/Allen, you’re creating what you believe to be a cool product that will revolutionise the world. But will people actually want it enough to pay money for it?

Once you start forming a company around your cool product, your sales people will sell it like crazy, but chances are the chasing of the sale will result in having to customise your cool product for every customer which makes the success of the company precarious due to slim profit margins.

Instead, by hiring a product manager who can research and identify what the market as a whole needs and wants (and most importantly: will pay money for), you can sell the one product many times rather than chasing your tail in a vicious cycle of selling many products once.

Share
 

Developing Software for Users

24 Aug

There is a common question asked in most companies I’ve gone to work for, and that is “How do we make software that people enjoy using?”

Well, I have news for you. Most people (me excluded) don’t like using software. Unless we are all lucky enough to do all of our work on an iPad, we’re going to experience varying degrees of frustration with the software we have to use, and we’ll avoid using software that is not an absolute necessity to our livelihood.

So how does a software company counteract the frustration most users feel towards their computers but still release products that users will buy?

Usability tests.

Have representative users come in and try out a prototype of your software concept. This will save you time in your development process, ensure you’re getting it right the first time, and help you to keep support costs down post-launch by making sure the software is easy enough to use that people don’t have to contact your company with ‘how-to’ questions.

There are many different approaches to usability testing, but you can do casual studies with 1 week and a simple mock-up on the cheap, or formal studies with a dedicated usability lab, cameras, screen capture, and an audience of developers. I’ve even done successful usability tests in a corner of a tradeshow booth. Even a small amount of qualitative or quantitative user data is going to save you time and avoid HCI design problems later in the development cycle when changes become more expensive.

And it pays off in the long run by giving you a product that people can use.

Share