Archives for Apr,2016

You are browsing the site archives by date.

Custom Development: Outsourcing Partnerships

There is no disputing that custom development outsourcing can be cheaper.  You can hire development firms outside the US (offshoring) that charge half the normal local rates. 

If you are thinking about custom development outsourcing, you’re doing your business a great disservice if you don’t consider partnering. 

The most common reason for custom development outsourcing is the reduction in cost. The reality of cost saving are complicated with 30% of companies reporting that it’s an effective strategy to reduce costs; 55% percent say it’s somewhat effective while 15% claim that it’s not effective at all.

If you are thinking about custom development outsourcing, you’re doing your business a great disservice if you don’t consider partnering.  Partnering, in this context, is about building a long-term strategic relationship with a local IT vendor who will help satisfy your strategic goals.
Partnerships allow for two companies to sync core competencies, expertise, and efficiency of scale to help each other achieve long-term success.  Partnership can be established in many forms:
  • Short-term development efforts
  • Long-term support and maintenance
  • Ad-hoc hourly support
  • Equity based ownership

Choosing a partner to complement your company’s culture and objectives can be challenging.  However, when done right each company can reap benefits.

custom development outsourcing statistics

Custom Development Partnering Benefits:

  • Collaboration
  • Sharing the burden and potential risk.
  • Access to more skills, knowledge and experience. Partnerships provide for a wider skill base, complementary experience, and knowledge. 
  • Better, more effective decision-making. 
  • The ability to look at problems from many angles can help to achieve better, often more creative, and innovative solutions.
  • Flexibility to use company resources on the highest priority strategic objectives.
  • Resource reduction: shifting the burden of staffing professional IT personnel and allowing a partner to do the staffing to accommodate fluctuating IT needs.
  • Infrastructure: Shifts the burden of purchasing, maintaining, and supporting costly IT infrastructure to a partner.

One80 Services is ready to partner with you on your next project.  Give us a call today.

Talk to Us Today

Release Planning – Reducing Silos, Creating Understanding

Release Planning is becoming a controversial topic in the Agile community. Purest are saying that if you are doing true Scrum you should release working software often – as soon as an MVP is ready.  The Team should be releasing frequently in order to learn from their customers and users.  I agree 100% with this paradigm; however, on large scale projects with many teams, stakeholders, dependencies, and risks this can be difficult.


We work with many clients who are developing larger software projects. In organization with multiple teams and product owners, priorities can be to coordinate.  These clients are not large enough to implement a full Scaled Agile framework, so release planning sessions gain importance.

I recently facilitated a Release Planning session for an organization which took an interesting turn.  The meeting became less about writing Epics and Stories, reviewing velocity, and charting a path towards release success.  Don’t get me wrong, we definitely accomplished these tasks.  The more important lesson from the activity, however, was getting everyone on the same page.

I started the session by asking everyone in the room to quickly define the scope of the next release on a post-it note.  It was clear from other conversations I had with the people in the room that they had already completed dozens of meeting to define the release.  I figured this was a no brainer.

I received about 6 different visions.  Not just slightly different but COMPLETELY different.  How could this be, how could the dozens of meetings not have generated a scope plan?  Simple: Personal Agendas.  Everyone in the room had a different agenda and view point (reduce customer complaints, simplify architecture, upgrade platform, introduce cool features, etc.).  Planning had taken place in silos.  Each department had meetings to discuss scope, but no one had ever brought the silos together.

We took a quick detour and spent an hour defining scope by listening to each person’s ideas, priorities, and customers needs and wants. At the end of the first hour we had a well-defined understanding, which helped simplify the release planning and give the Product Owner and Team a cross-functional release target.

On large scale projects with many teams, stakeholders, dependencies, and risks – sometimes reducing silos and creating understanding before building a release plan is the simply the smartest way to go.

Talk to Us Today
post =