Dedicated Software Teams vs Project Delivery

Why the manner in which you structure your engagement is more important than who you choose to partner with.

When businesses choose to outsource the development of software products, the initial question is usually which company should they engage with?

While selecting a partner is certainly an important task, perhaps even more critical is determining how you plan to structure your partnership.

The primary engagement models used in modern day software outsourcing include:

Dedicated Software Teams (Think of this as your “virtual tech team” – where you hire individuals to develop software exclusively for your specific company).

Project Delivery (Think of this as “an all-inclusive software package” – where you hire a vendor to build out a software application that has limited scope; however, once you hit the milestones outlined in the contract, the application becomes fully complete).

Both types of engagement models have the potential to succeed, as well as to fail.

The KEY to whether one works better than another will ultimately come down to what fits your business needs and has been proven successful over time. (In other words, there are no liquid assets.)

This article seeks to illustrate the differences between Dedicated Software Teams versus Project Delivery; to help you better understand where these two models work best; as well as to guide you to easily identifying which is the correct model for you based on expected results.

Definitions of each engagement model

Dedicated Software Teams are those services that provide long-term ongoing support, i.e., a dedicated team of programmers/engineers will develop and support software exclusively for your company.

The dedicated software team would typically consist of developers working regularly over time with a known monthly fee/retainer fee schedule; the developers on the dedicated team have no outside commitments.

Project Delivery services provide fixed-scope defined projects or applications with clearly identified timelines with set deliverables upon completion.Typical characteristics:

• Fixed scope, cost, and time
• Initial requirements are completely defined
• Short engagement for the duration of the project
• Delivery is controlled by the vendor
• Minimal involvement post-delivery

Delivery is a transactional process, designed to optimize predictability rather than adaptability.

The Core Differences between Dedicated Software Teams and Project Delivery

1. Accountability and Ownership

Dedicated software teams

• Are accountable for delivering results, not just completing tasks.
• Build knowing the product and the market over time.
• Use experience to make better decisions about the product.

Project delivery

• Has a focus on the completion of project-specified scope.
• Accountability ends with the project’s completion.
• There is little to no incentive to plan for the future.

Ownership builds up over time and is beneficial to dedicated teams.

2. Flexibility and Change Management

Software requirements change continuously.

Dedicated teams

• Manage changing priorities on a sprint-by-sprint basis.
• Support fluid product roadmaps.
• Enable continuous discovery and iteration of knowledge.

Project delivery

• Discourages changes to the scope of a project, therefore discourages creativity.
• Penalizes fluid product requirements and margins.
• Creates potential for a break in the support chain.

When the product roadmap is fluid, project delivery becomes a bottleneck.

3. Temporal Speed

• Project delivery appears fast in the beginning.
• However, over the course of the relationship:
• Onboarding must occur every project.
• Context must be rebuilt.
• Velocity decreases between projects.

Dedicated software teams
Become increasingly fast with the length of their relationship.

Project Delivery Costs

The upfront cost of a project delivery method is generally lower than for its later phases, because:

• The cost structure of a project delivery is based on fixed costs.
• The cost structure has a defined limit on the size of the project (i.e., there will not be increase or decrease in cost).
• There is no uncertainty associated with project delivery, meaning that once you deliver, you know what the final product will be.

There are also “hidden” costs. The hidden costs of project delivery include:

• The rework involved in product launches.
• The rework involved on system changes after a customer request.
• The rework that results from accumulating technical debt.
• The rework resulting from switching from one vendor to another (i.e., “switching costs”).
• The rework that results from having no prior knowledge of the product before beginning the project.

Dedicated Software Team Costs

When you are planning to develop an application/product, there are also additional ongoing costs to support the software development team:

• Establishing an ongoing monthly retainer with a vendor.
• Long-term commitments to resource needs.
• An agreement with the vendor to assist in delivering the project outcomes.

In order to maintain total cost of ownership for the product following launch, there will be many times when a dedicated team will relieve your company’s:

• Rebuild costs
• Context switch costs
• Hiring overhead (i.e., you won’t need to hire additional staff to assist in software development).
• Delivery risks (i.e., you will continue to be viable over time).

Dedicated teams can reduce total costs of ownership on products that are expected to live beyond the product launch.

When Project Delivery Works

There is nothing intrinsically wrong with the project delivery model. However, the project delivery model is not as broadly applicable (i.e., water-fall funding) as other project management models.

Project delivery is best suited for projects with:

• Defined/limited scope
• Specified = validated requirements
• Short timeline
• Low product complexity
  Project delivery has limited application to products, where the product’s problem or requirement (i.e., fixed) must be maintained to a degree for an extended period after launch.

This does, in fact, mean that project delivery may be an efficient approach when the problem to solve is continually stable.

When Dedicated Software Teams Win Over Project-based Outsourcing

Dedicated software teams can outperform project delivery on many of the following occasions:

• When you build a software-as-a-service (SaaS) product.
• When your roadmap is dynamic and frequently updated.
• When speed of iteration is important.
• When you need to continue to manage technical debt over time.
• When you value long-term scalability of your products.

Most successful product companies will ultimately transition away from project delivery against dedicated software teams.

Challenges Associated with Delivery Method

The Delivery Method has:

• Assumptions that may not be aligned.
• Gaps in Scope & Expectations discovered too late.
• Limited accountability after launch.
• Team members only have the motivation to “deliver & leave.”

Dedicated Software Teams have:

• High Product Ownership demands.
• Defined Performance Metrics.
• Team Work Collaboration required.

The challenge with dedicated software teams can be resolved.

The Project Delivery method has primarily structural risks.

Quality and Technical Debt Considerations.

The Primary Functions of Project Delivery Teams are:

• To complete all tasks.
• To meet the accepted standards.
• To swiftly close Tickets.

The Primary Functions of Dedicated Software Teams are:

• To maintain the quality of the code.
• To increase the quality of the architecture over time.
• To achieve the right balance of rapidity versus stability.

The Technical Debt in Project Delivery Models accumulates silently, and ultimately is expensive after the project is launched.

Differences in Communication and Collaboration.

Dedicated Software Teams:

• Engage in Daily or Weekly SCRUM Meetings.
• Are involved in Planning and Retrospective Meetings.
• Share responsibilities for decisions with all involved.
• Are in close alignment with their Stakeholders.

The Project Delivery Method:

• Heavily Depends on the Quality of Documentation.
• Minimizes Communication after the Project is Completed.
• Has Limited Opportunities for Collaboration on Project Milestones.

Modern Software thrives on Feedback and Engagement.

Figure Out Which Model Will Work for You.

Things to ask yourself:

• Will the Product Change After Launch?
• Do We Anticipate Roadmap Changes?
• Is Speed & Velocity Greater than Predictability?
• Do We Want Our Engineers to Be Owners of the Product?

If you answered “Yes” to most questions, Dedicated Software Teams are your Best option.

If you answered “No,” the Project Delivery Method will work.There is a recurring pattern among businesses:

• Launch an MVP using project delivery
• Release the product into the market
• Determine new requirements as they arise
• Build up a backlog of technical debt
• Have a dedicated team create new assets to support the product development process.

Companies that bypass the fifth step spend less time and money than companies that follow this pattern.

In conclusion, there is no single best way to develop software products; there is, however, a better way for:

• Product continued development
• Scaling up product output
• Regularly and continually improving product functionality
• Supporting and sustaining the ongoing evolution (Engineering Maturity)

The project delivery method provides feature value, whereas dedicated software teams provide capability to create and sustain the quality, reliability, and capability of a product.

When software is an essential component to a business’s value proposition, ownership of the software becomes critical – and dedicated software teams own the product from start to finish.

Extended FAQs