The Seven Deadly Sins of Outsourced Development: A Guide for Clients and Contractors

The Seven Deadly Sins of Outsourced Development: A Guide for Clients and Contractors

By Max, CEO of BandaPixels

Outsourced development often evokes strong feelings, sometimes even animosity, similar to the frustration people experience with construction projects. This stems from a relatively low barrier to entry, where anyone with basic technical skills might portray themselves as a large, established firm.

This article explores common pitfalls in working with outsourced development teams, offering guidance on managing such projects effectively. It's essential reading for both clients and contractors. While a single article can't encompass years of experience, it highlights frequent mistakes and pain points.

Disclaimer

I've been on both sides of the fence, working for outsourcing companies and as a client in startups with minimal budgets and large enterprises with multi-million dollar contracts. My perspective spans various segments, encompassing both contractors and clients. Everyone makes mistakes, and simply blaming outsourcing firms is an unproductive approach.

In my work, I frequently encounter projects in dire straits. A consistent pattern emerges: the reasons for a project's near-failure are typically simple and relate to disruptions in production cycles and a disregard for common sense. If your project, or a project you're working on as an outsourced specialist, seems to be heading for disaster, remember you're not alone.

When to Hire an Outsourced Team

Similar to home renovations, if your budget is limited, you need to understand the development process. With a sufficient budget, hiring a competent team to handle the complexities is advisable.

A key misunderstanding, especially with large-scale projects, is that clients aren't just buying code; they're buying project management. They're choosing managers who can create a predictable and transparent client environment.

Clients should actively engage in this environment. There are three main scenarios where outsourcing is suitable:

  1. Client Proficiency: The client understands the development process and can easily communicate with developers, overseeing the project effectively.
  2. "Hands-for-Hire": The required work is linear and well-defined, requiring implementation rather than innovation, managed by an internal employee.
  3. Investment and Time Constraints: The client has funds for experimentation but lacks the time to build an internal team, often the case with investors managing multiple ventures.

If you identify as an investor, further research on intuitive project launches is recommended.

Outsourcing is generally not recommended for startups with minimal budgets and no understanding of IT product development. However, resources are available for those willing to learn.

Two main contract types exist for outsourcing, chosen based on the project's goals:

  • Fixed Price: Suitable only when both client and contractor have high competence levels. Ideal for projects with a clearly defined final product.
  • Time & Material: An hourly rate format. Often more flexible and cost-effective for startups or linear tasks, as it mitigates risk for the contractor.

Seven Ways to Avoid Project Failure

Let's examine common mistakes and misconceptions that hinder effective collaboration.

The Client Isn't Always Right

The adage "The customer is always right" needs clarification. It originally meant "The customer is always right in matters of taste." This refers to preferences, not dictating every aspect of the project. Clients can be difficult or lack sufficient understanding. We must guide them while ensuring both parties are protected by the contract.

Create a Product Vision and Technical Specifications

Ignoring technical specifications (TS) is a primary cause of outsourcing project failures. The TS is the most crucial, expensive, and complex part of the project.

Mistakes at this stage have cascading consequences. A small initial error can escalate into uncontrollable chaos. Everyone on the team reads the document, and this reading time should be accounted for in the budget. A poorly written TS wastes time and money, leading to clarification calls and additional documentation. Experienced staff should be involved in creating the TS, further impacting time and budget. The TS is not just a checklist item; it's a tool for aligning the visions of the client, contractor, and other stakeholders.

Before the TS, a Product Vision document should be created after signing the contract. This outlines the project's background, reasons for launch, success criteria, product concept, and philosophy. It's not a set of acceptance criteria, but a shared understanding of the project's purpose.

A significant failure I witnessed involved a 10,000-hour development project with a 700+ line Excel spreadsheet listing features like "Email Registration" and "Guest Invitation" instead of a proper Product Vision. This led to inaccurate estimations and a delayed release.

If you're hiring an outsourced team without a TS, commission them to create a Product Vision for a separate fee. This absence can double the project's timeline and triple the budget.

Create Phased Contracts

Contracts should not attempt to encompass everything at once. Divide them into stages, such as Product Vision development, TS creation, MVP specifications, etc. At the outset, a full understanding of the project's scope is unlikely without a clear visualization in the form of prototypes or an MVP.

Crucially, include a change management policy and a communication protocol in the contract, avoiding vague terms like "automatic acceptance."

Product Tasks Should Remain with the Client

Outsourcers excel at execution, not strategic thinking. The client should own the vision. Tasking an outsourcer with developing the vision will result in the simplest, quickest, not necessarily the most innovative solution.

Don't Try To Eat the Whole Elephant At Once

Follow a structured approach: design, prototype, then development. This applies to all development stages:

  • Proof of Concept (POC): Validates the project's feasibility.
  • Minimum Shippable Product (MSP): A functional product that allows for technical refinement.
  • Minimum Viable Product (MVP): A basic product ready for release.
  • Minimum Lovable Product (MLP): A product that delights users.

Parallel development to save time is counterproductive. Each stage should deliver value. Complete the design for the POC, then prototype, then develop. Repeat this for MSP, MVP, and MLP.

In large projects, a "No-Code MVP" stage can be beneficial, using simple services or clickable prototypes built with no-code tools. This offers a working prototype at a lower cost, demonstrating the product's functionality and facilitating budget approval. It also allows for identifying and addressing issues before coding begins.

How to Fit This Elephant in a Fridge

This refers to violating production cycles and business processes, often by attempting to create a coded prototype from the start or lacking a change management process. Any new idea should be assessed for its impact, planned, and integrated properly. Don't rush into development, even under pressure.

Divide and Estimate

Project estimation requires specialized skills. Estimators should avoid estimating based on their own implementation time. Instead, they should consider factors like documentation, client responsiveness, team composition, TS quality, resource allocation, etc.

Pre-sales teams should also possess estimation skills, as they are selling project management from the outset.

How to Stop Hating Each Other

Understanding each other's logic, goals, and challenges is crucial. Client-side frustrations often arise from contractors agreeing to unachievable conditions. Contractors may try to "reuse code" from other projects, leading to bugs and architectural issues. Sales managers' KPIs tied to deal value, not profit, can lead to underpricing. Clients sometimes prioritize cost over quality and disrupt development processes. Project managers must balance innovation with budget and scope.

Conclusion

Effective collaboration requires mutual understanding. Conflicting goals are normal. Finding balance within the team is also essential.

Having experienced both sides of the outsourcing relationship has provided valuable perspective, allowing for a more understanding approach to problem-solving. This article aims to provide you with that same understanding.

要查看或添加评论,请登录

Max Obrazchykov的更多文章

社区洞察

其他会员也浏览了