Oct 112012
 

This is the final installment of our four part series on the challenges of outsourced software product development. If you have been following along, you know this is a fictional story based on experience from both sides of the business – client and vendor. If you haven’t had a chance to join our story until now, here are links to parts one, two and three.

Over a long lunch, Steve Trask, CEO of STApps, has been giving his friend Don Steward insight into the issues and decisions he had to deal with to successfully outsource on-going development for his SaaS application. Before this conversation, Don had considered his options and decided he would outsource the development of a new app for the suite Steward Software offers. He felt the market was right, but he wasn’t sure he was ready for his first attempt at outsourcing. He had invited Steve to lunch for this discussion, but now he wondered if it was going to do more than just make him confused and wary.

Off to Europe

Location – Where is it? How does it impact communication?

Steve was describing his trip to Europe to find a replacement for his outsourced team in India.  He had decided that his recurring problems with miscommunication, rework and delay were in many ways products of the separation in time zones, organizational cultures, and environments he had selected when he engaged providers. The people he was working with were talented and dedicated, but for the continuous release cycle of SaaS apps, it was a difficult fit at best.

After talking to some friends, Steve had taken a trip to Europe to meet with four companies and see if he could find a situation where there was some day overlap for direct communication. He knew it wouldn’t solve all his problems, but it would certainly make it easier to have a close relationship with his outsourced development team. The last of the four companies he met with was a small group headed by Milan Andresen, a sharp, young entrepreneur that caught his attention because he was competing successfully in a very tight market.

Steve felt Milan and his group could work out to be a strong partner, but he also knew that because of the tight market, Milan didn’t have enough cash flow to quickly bring together a new team for STApps. He decided to offer Milan a partnership deal, although he knew it would slow the project down initially. Milan was cautious, but intrigued by the idea. Funding was not easy to come by in the current economic situation. The offer gave an opportunity raise his cash on hand and move to a stronger financial position. For both men, it seemed like it might offer them something they hadn’t had before. Steve would get more control with a team that they could work with directly and Milan would get a long term engagement that would spread his risk better and give his company a financial boost.

Partners in Outsourcing

Over the next month, the two men worked out the legal and financial details of the arrangement while Milan assembled candidates for the STApps dedicated team. After interviews and coordination with Steve’s product team, they got down to work. There were hurdles because the team in Europe was new and Steve’s team in Boston had to “unlearn” some of their assumptions about working with remote teams now that they had a much closer relationship. But overall, Steve felt it was a good, working relationship.

Steve and Milan had many conversations over the next year. At first they were mainly about the work being done for STApps, but they had a business partnership too – so Milan shared his operational concerns as well. It was a side of outsourcing that Steve had not thought about. One of the first issues that presented itself, was a death in the family of Henrik, one of STApps dedicated team members. Family obligations required Henrik to be away from the office for a couple of weeks. He could work remotely, but he couldn’t commit to his normal output. As Steve saw it, team was past the early stages of formation and beginning to reach stable throughput. Team commitments were being met and his product manager’s faith with the team was growing. Steve couldn’t afford to lose Henrik over a family commitment no one could control. He also couldn’t bring in another team member without going through all the stages of team formation over again. He decided to put it to his team and let them decide if they could make things work while Henrik was away.

Team Dynamics

The team worked out ways to have Henrik work remotely during his absence and to add some extra effort if it was needed.  A disaster was avoided. Steve took the lesson to heart. The partnership was working well. He was much closer to his team and felt he had more control. But, with that control came more direct responsibility for maintaining the availability and productivity of individual team members. If someone was injured, offered a better job somewhere else, or not performing – he had to know and help decide on the best course of action. Maintaining productivity and a strong team dynamic meant they had to have contingency plans for normal interruptions.

As their conversations broadened to cover other aspects of the business, Milan began to discuss a related problem that concerned him. Most of his clients were contracting under a dedicated team arrangement, similar to the way Steve was working but without the financial ties of a legal partnership. Milan had one team that had worked for a major European banking software provider for over two years. The relationship was solid but the work was maintenance and enhancements of a small group of applications specific to banking. The technology was anything but cutting edge and frankly, for a group of young developers, the tasks seemed repetitive and boring. The team had built a strong base of knowledge in the specific applications they worked with – which made them invaluable to their client because the original development group had been disbanded. But Milan could see that motivation within the team was becoming a problem. He needed to consider ways to give team members opportunities to do other things and work with other technologies or it was likely some members of the team would leave.

It was a risky situation. In a small company, a single client can represent a large share of total income. If Milan couldn’t maintain his team stability, he could lose the client. If he couldn’t find more ways to motivate his team members, he could get into a situation where he had to fill more than one position in a relatively short period of time. They could handle a one or two replacements across different teams, but if multiple vacancies came up on the same team in a relatively short period of time it could be devastating.

Motivating Individuals

Steve could understand both sides of the situation. Instability within the team, loss of productivity, or lowered attentiveness in developing requirements could trigger a client to consider moving their work to another company. Just bearing down on the team members – micro-managing them – wouldn’t improve their motivation or make them more efficient. Both Milan and Steve knew they needed to rotate team members to help them break out of the rut they felt they were in. For the sake of their partnership, Milan and Steve needed to have fewer project silos so they could backfill a position with someone from another team in a less critical position. Setting up an approach to team member rotation wouldn’t solve every problem, but it would lower their risks and improve staff retention.

Looking at Don, Steve sighed, “That’s where we are today. We’ve just begun to work out how we might handle rotation. We haven’t figured out what impact it might have on our client contracts and relationships. We haven’t actually tried it yet. It is going to take a while to make it work, so it will be a while before we see the benefits. I can’t back away from it without breaking the partnership apart and really I don’t want to. These are real problems we’re solving and if you are into outsourcing application development of a product for the long run, the problems I’ve had I will have anywhere I go.  I hope that was helpful.”

Don thought about it for a second. “Yes,” he said. “I’m going to need to sort through my thoughts tonight, but I think I see a lot more now than I did. Thanks Steve. I didn’t intend for us to take this long, but I’m glad we talked.”

Lessons Learned

That night, Don went back to his notepad. What had he learned?

Key Points

  • For product development, real-time communication is critical. Time zones, language – they cannot be allowed to be a barrier.
  • Hourly rates are only a part of the total cost of an engagement.
  • A product manager has to be available to the development team whenever they are needed.
  • Layers of organizational overhead don’t lower risk by themselves.
  • Cultural fit, both personal and organizational matters.
  • A successful outsourcing relationship is a partnership where both sides have enough at risk to be focused on success.
  • The iron triangle exists. Both sides of the outsourcing relationship have to pay attention to scope, resources and schedule while maintaining quality. Outsourcing does not lessen the need to be involved with the development team.
  • Shared processes, commitments and goals that tie the entire team together work better than just handing responsibilities off between the two sides of the relationship.
  • Team dynamics and motivations are critical to understand and manage to maintain productivity and commitment.

Looking at the list, Don could see one thing stood out – communication. If the outsourcing relationship included strong communication, directly with the development team and covering more than just daily tasks, it was likely to be successful. The big picture, on both sides, was just as necessary as the small details of a feature. Communication built trust, understanding and shared goals. The rest of the issues were a normal part of any software development project.

If that was the case, where should he start? He didn’t want to go the route Steve took and buy his way into a partnership. He wanted to be able talk to his team in real time. Effective product development for an application is a creative effort and requires a lot of team interaction. He wanted to be able to travel to their site or have some of his remote team visit him if needed. He wanted a company that understood the issues and would work with him to solve the inevitable problems.

For Don, that meant looking for partners specializing in outsourced product development in the Americas, preferably North America. The decision narrowed his search and the discussion with Steve gave him a list of questions to ask.  There are no perfect answers, but having them would give him a better understanding of the prospective partner.

Questions

  • How do you handle communications between your development team and the client team? What applications and tools do you use? What hours do your teams work?
  • What development methodology do you use? If it is agile and scrum-based, what involvement will the client team have in daily status meetings, scrum planning, retrospectives, etc?
  • What kind of projects do you typically do? Enterprise IT or product development? What do you think are the main differences between them?
  • How do you envision the quality assurance process will work?
  • What is your experience with release cycles and maintenance windows for SaaS applications?
  • How is your infrastructure set up? Do you have an IT group? What will you do if there is a power outage, Internet failure, server failure or local disaster?
  • What is your process for putting together a new team? What involvement do you expect from your client?
  • Will the entire team be able to speak, read and write English well enough for documentation and open discussion?
  • Is there someone who will monitor and actively discuss team dynamics for the entire team? An account manager? Who will help resolve issues as they arise?
  • What is the average size and make up of your teams? How many project teams are you running at one time?
  • What is the longest period you have maintained a team for a client?
  • Do clients visit your site? What are the barriers to having team members visit client offices?
  • How long will it take to bring together a team once you have project requirements? How long do you imagine it will take for them to be productive?
  • Do you have references from clients that I can speak to?

So – that is our story. Don will find a partner, how it works out will depend on many factors, but he feels he is ready to make decisions and move forward.

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>