I am a manager, coach, speaker with more than 15 years in business mostly in IT, Advertising and Training industry working on Agile leadership and project management challenges with such companies as Cisco, Intel, or Unilever. I use my creativity in everything from running workshops to facilitating teams and fostering change. I am responsible for Selleo’s awarded recruitment process.

Dariusz Wylon

Grzegorz supports smart technically-minded people as a business consultant and COO.

Grzegorz Rduch

Software companies providing outsourcing services usually prefer time-and-materials pricing model rather than fixed-price one. With the use of time-and-materials, the project time is approximately estimated, but the final cost and date are not defined, clients have the possibility to add changes on the go and payment depends on the hours spent (hourly rate). With the fixed-price engagement, clients cannot make the changes during the development process (unless the contract is amended) and the project scope, deadlines and final price are set at the beginning of the collaboration. At first glance, this (fixed-price) could be tempting as it sounds like a promise of delivering what you need with the time frame and costs of your choice. So what are the key reasons showing that time-and-materials model is most beneficial for both a client and a service provider?

### **Competitive advantage with user-centric approach and market sensitivity in mind**

With the ability to change initial requirements and improve features throughout the development process, you gain the flexibility to follow market trends or switching customers needs. You can quickly adjust your ideas to the current business environment, and influence the scope, features and delivery plans to gain successful project and high-level technology-implementation quality. Unlike the fixed-price model, hourly rate approach ensures business-level control on your project. You can, for example, decide, based on your current situation, if you prefer tweaking the scope and adding some extra nice-to-have features or spend additional time on code quality.

### **Involvement in the process and ability to stop the line**

You are the one who sets the backlog priorities, software developers follow your business-value track, and after the project kick-off, you are benefiting from the synergy between your domain knowledge and the technological expertise of a development team.With this kind of engagement, the project can evolve, as you are using the skills and experience, the company gathered while working with previous clients within same technology, industry or business domain. Short feedback loops, allows you to stop the line and change the direction of the project to end up with the best outcome at a given time. There’s no need for contract renegotiation or several meetings to estimate new specifications.

### **Business risk reduction and control of costs**

As the fixed-price contract scope no restricts you, it can be pretty sure that the outcome will fully correspond your expectations. You possess the total control over both deliverables and the budget. Instead of developing the complete project you can decide to focus on the MVP first and then check if some changes in the requirements are needed. Developers can code with quality in mind, and you are charged only for the actual work and time spend on your project. You can track the progress and decide which way to go from your business and financial perspective. If you think some features are to cost or time-consuming, you can always change it or remove from the backlog. Moreover, in contrary to fixed-price engagement, you can decide to terminate the agreement if you are not satisfied with the code quality, skills or communication.

### **Fixed-price use-case scenario**

Fixed-price contracts make sense when the outcome of the collaboration process is a small software project with precise requirements, set specifications and defined timelines.

If, at the beginning of the partnership you are sure that

\- you won’t change the scope of the project (there will be no need for additional features, functionalities, device or browser compatibility),

\- your project is deliberately short and easy to implement,

\- you are convinced about the outcome of the process,

\- the business environment you are providing the solution for is stable, and there will be no need to enhance the project in future,

\- you can compromise on code quality,

\- your clients’ needs are evident, and you’ve conducted some research with the target audience to confirm them,

you should discuss the fixed-price pricing model.

### **Summary**

Agile methodologies require time-and-materials pricing model. The client’s ability to be involved in the development process, prioritize backlog and adjust to the end-users’ needs with evolving requirements are, in most cases, the key to the market success of a service or a product. And as a result of such partnership, you will, from the very beginning, receive a working software solution which, after a few iterations, become a well tested and 100% functional system. You are the owner both of the code and the process and can decide what is most important right now and which way you would like to go to reach your business goals.

Agile methodologies require time-and-materials pricing model. The client’s ability to be involved in the development process, prioritize backlog and adjust to the end-users’ needs with evolving requirements are, in most cases, the key to the market success of a service or a product.

3 Reasons Why You Should Use Time And Materials Pricing Model For Software Outsourcing

Sometimes outsourced development projects fail. Study post mortems documenting such failures or talk to people who were involved in failed projects, and you will discover that failure was often rooted in mediocre team organisation and meager management practices. Team architecture was poorly defined, roles and responsibilities of each individual were not documented or understood and ownership was not clearly divided. Finally, and possibly most importantly, the key roles on the team were filled with people who just did not have the makings to make it work. Who are the cornerstones of the team architecture you need to outsource software product development successfully?

### **A John Wayne solo act?**

Product championship calls for a powerful combination of both** business/market and technical** skills. Ideally, you would like to have ONE person to be able to provide the complete skill set needed. Even if you find one, the tasks, duties and responsibilities associated with such a large role are so numerous that they may be too expansive for a single individual to manage. Consequently, a team of TWO people are much more likely to cope with the challenge and ensure the combined market/product, technology and process leadership you are after.

### **The tandem that pulls it off**

So, in principle, you will need at least two key players as the foundation of your team structure. One to manage the front-end, **customer-focused** part of the development process and the other to take care of the back-end,**technology-oriented** product development job. If you are a fan of [S.G. Blank](https://steveblank.com/), you may as well think of the two as the managers of Customer Development and Product Development processes respectively. The first thing thing is to ensure both perspectives and skills are at hand, and the next is to ensure they smoothly act in sync. Get both on your team and ensure they collaborate effectively, and you are much more likely to create a great product.

### **The Product Owner**

Your product champion, leader or owner – whatever you call them – has extensive domain expertise and great empathy for the customer/user. This understanding allows them to see what is essential rather than incidental and helps them ensure a good product-market fit. As regards organization, this person is usually the entrepreneur founding a new venture or an entrepreneurial in-house manager responsible for: _ the delivery of the project _ product management day-to-day interactions with customers/users, the outsourced team and other project stakeholders A word of caution. If you split the role into Project Manager and Product Owner, specify clearly their areas of responsibility and the associated TDRs to ensure ownership and clear lines of communication.

### **The Tech Lead**

Your Tech Lead or Chief Engineer – again, the formal label does not count as much as the contents of the role – has the expertise to see what is possible. This person co-creates the product through technological insights and contributions. They are usually in charge of the product development team and supervise product development activities on a daily basis. They are to free the Product Owner from the time-consuming management of developers at the task level. A word of caution is in order, however. Even if the Tech Lead is your in-house co-worker, establish a delivery manager at the vendor with full responsibility for development team management. The vendor’s manager should accept responsibility for any work delivered by your vendor’s staff and act as a single point of contact for efficient communication and decision making.

### **Let the team architecture unfold …**

If you have the Product Owner and the Tech Lead who feel personally responsible and accountable for the success of your product, or even better, who identify with the product, you may assume you have a solid foundation on which to lay the rest of your team . You can now begin to further define its architecture. Whatever the details, clearly specify the structure of the project team, accounting for both internal and vendor resources you will need. Specify roles and the associated responsibilities, document them and ensure they are understood by all the people involved.

### **A note on outsourcing**

How should the roles be located within the team if you outsource your software product development? You are unlikely to outsource the Product Owner’s job, if only for the fact that the near-/off-shore vendor is ill-suited to manage the front-end, customer-focused part of the development process. Still, it does not mean that great, proactive teams are unable to go beyond the technical and offer valuable product and business insights. Unlike the Product Owner, the Tech Lead may be either your in-house co-worker or the vendor’s manager, depending on the skills and resources available in-house. In the latter case, they both need to be prepared for intense collaboration to keep the customer and product development in sync. As a rule of thumb, the more agile the methodology and the less precise the technical specification, the more frequent the communication exchange between the two key players needs to be. As such, your Product Owner and the vendor’s Tech Lead lend themselves to act as a single point of contact between you/your company and the vendor. Such an arrangement facilitates fast decision making (which need not preclude collaboration on a wider basis between you and the vendor’s team.) If you are not the Product Owner yourself, make sure the one who is has sufficient authority to act efficiently, i.e. to approve the work delivered. Ultimately, both sides want to avoid unnecessary delays and frustration which may otherwise burden their collaboration. It is also helpful when the Product Owner has some technical background while the Tech Lead has a degree of domain knowledge gained on earlier similar projects. Such expertise overlap allows both to better understand each others’ role and vastly enhances the efficiency of collaboration.

### **Who to look for?**

All in all, while sourcing, make sure you carefully select not only a software development house, or rather a team, but also – possibly, first and foremost – a key player to be a cornerstone of your team. Do not simply purchase a service – hire people to work on your project team. Set selection criteria and conduct due diligence on both the company and the specific individuals you are to collaborate with – in particular, the person leading the vendor’s team. Look for an individual who: _ has sufficient** communication and cross-cultural skills** to ensure smooth collaboration _ possesses rich **technical expertise** you need for your project and thus is able to make significant technical contributions _ preferably, **knows the application domain** so that you do not spend much time getting them in the picture _ is able to present a **proven track record** of experience on similar-size-and-type projects delivered successfully leads a stable, cohesive **team** that follow a well-defined software development **process** Last but not least, make sure the Tech Lead is the person you / your Product Owner feels comfortable to work with and the attitude is reciprocated.  After all, you are both in for intense collaboration in the months, if not years, to come. I am not trying to say you are hiring an individual. All I am saying is that this individual is key to outsourcing successfully.

### **Sourcing Tips**

How can you increase the odds of finding the right person? _ Scrutinize their personal profile / CV. _ Browse through their professional networks. Are they likely to scale their team fast enough when needed? _ Check their personal references, in particular the references from the customers they have served. _ Conduct interviews with the Tech Lead and their team. _ Check the projects the Tech Lead delivered – not necessarily only their company’s. On larger engagements, you may as well: _ visit the company or have the Tech Lead come and deliver initial service, e.g. tech spec and system design, on-site have them deliver a pilot project. It is the Tech Lead and their team that need to convince you they have the expertise with the specific technology stack and have successfully completed projects for other clients using your target technology. All in all, apply recruitment tactics on top of more formal B2B purchasing procedures. All of it should have one objective in mind – to establish if the candidate has the makings to lead your back-end product development team and ensure you outsource successfully.

### **Conclusion**

To sum up, when organizing the team to deliver your software development project, make sure it has a solid foundation in the the form of a tandem of a Product Owner and a Tech Lead. Fill in the key roles with the right kind of individuals before you embark on the project, and you have vastly increased the chance of being a success in your quest.

Sometimes outsourced development projects fail. Study post mortems documenting such failures or talk to people who were involved in failed projects, and you will discover that failure was often rooted in mediocre team organisation and meager management practices.

Key Players In Outsourced Software Product Development

## **What’s your approach?**

Outsourcing entrepreneurs and firms vary greatly in the way they manage the sourcing process. Some progress through it speedily and are fairly spontaneous in their approach. Others take their time and use a systematic process to specify their needs, identify potential service providers, filter through the candidates and eventually select the vendor to deliver on their projects. Some are more likely to rely on their gut feelings and intuition, while others seem to stay emotionally detached and use their brain rather than their heart in the process. **Those with a more mature sourcing process are more likely to identify and select the right service provider. Many outsourcing failures have their roots in a badly managed sourcing process.** If you agree with the opinion, what are some of the practices and process steps you might apply to increase the likelihood of finding the right service provider? What follows is a brief account of what the more demanding outsourcers do while prospecting for vendors. Hopefully, the text will offer some food for thought for those who are about to outsource and are in the process of looking for provider(s). Note that you do not need advanced software tools to implement the process below. A simple excel spreadsheet will often do. If you prefer a tool, you might google for one and find some such aids as the[ Website Vendor Selection Tool](https://www.demandmetric.com/content/website-vendor-selection-tool) or[ SupplierSelect](https://www.supplierselect.com/), to name just two examples.

### **1)** **Compile a list of criteria your vendor should meet**

Before you start looking for a vendor, think through your project and establish what is to be done. Divide the scope so that it is clear what is to be delivered by the vendor vs. what is to be delivered in-house. **Having defined the scope of work for the service provider, you can now compile a list of criteria your vendor should meet.** The selection criteria one uses should directly relate to the characteristics of your project as well as to the tasks, duties and responsibilities to be undertaken by the vendor. Some such criteria will be very **specific**; however, do not waste time reinventing the wheel. Instead, search for and utilize the lists compiled by others. Just modify them to fit the specifics of your project. 

* specify WHO is to meet the specific criteria you choose** – is it the vendor’s **company** as a whole, the **team** which would deliver the service or a specific **individual** at the firm, e.g. the vendor’s Project Manager / Team Lead?

Financial stability, for instance, is naturally connected with the company. As regards accumulated experience, however, you would be able to make a better decision knowing what the specific team / individuals have delivered so far. An overall company portfolio may not paint a complete picture of what the specific team offered to you have contributed to the vendor’s track record. As a rule of thumb – by default – assume you recruit a specific team / specific individuals and rate them rather than the firm. Only when a criterion clearly relates to the organization should you assess the vendor rather than the team. Accordingly, while gathering information in later stages, be specific and ask for information on the team and the individuals to be involved when appropriate. For the sake of convenience, **the criteria are sometimes grouped into broader** **categories**, e.g. technology, business, communication, etc. The more criteria you are going to use, the bigger the benefit you gain from the practice.

**Output**: a set of (categorized) vendor assessment criteria

### **2) Weight the criteria selected**

Projects differ in character. Some are, for example, small and may easily be delivered by a freelancer rather than a team. On top of that, those who outsource differ in their specific requirements, e.g. a bootstrapping entrepreneur views price differently than an existing SME with a consistent revenue stream and a budget set aside for the project. Accordingly, **some criteria matter more than others. It is time to capture that fact in your selection tool**:
* weight the criteria you selected in the previous stage. If you divide the criteria into categories, you may weight the whole groups before you move on to modify the weights for specific criteria within each category.
In other words, you may choose to weight both the groups and the individual criteria within each group. Some of the criteria, i.e., the critical **ones, should be marked as such. For example: 
* expertise / experience in your technology stack (programming languages, frameworks, etc.)
* determine the top three technical skills that are the most important to you and therefore that the developers should possess.
* check whether the projects the company has worked on overlaps with your project type and size
* make sure that your team will consist of both senior and junior developers
* take into consideration is the time difference between you and the outsourcing company

A candidate vendor who fails to meet a critical criterion should be automatically eliminated, however high they score on the other criteria.

**Output**: a set of weighted vendor selection criteria

**3)** **Compile a vendor list**

Now that you, hopefully, know quite well what/who you are looking for, **create a list of outsourcing vendors who are likely to meet the set of criteria you have chosen**. Cast your net widely, but sift through the findings and ignore the vendors who clearly fail to meet the key selection criteria. **Where to find the vendors?**

* your network may know companies to recommend,
* organic google search seems to be the preferred tactic,
* use some technology-specific catalogues and listings. 

Having completed the search, you should have a solid list of candidates for further scrutiny.

**Output**: a list of potential service providers

**4) Gather and verify the information about the vendors listed**

With the criteria and potential vendors listed, it is now time to **gather and verify information on the vendors**. So, do some digging and learn more about the candidates selected so far. You can start off by asking the service providers to deliver the information needed as well as to rate themselves, i.e., their company / team against the criteria you find important. Convert the (key) criteria into a list of specific **questions **and e-mail them to all the candidates for answers (a list of criteria-based questions can be found at the end of this article). On the whole, the longer the list of questions you send, the lower the response rate, so make sure you do not cross the point beyond which you receive too few responses.

Additionally, you may augment your initial search by using the **information available online**, e.g. you can check what the vendor say about themselves in their marketing collateral, what the social media contents connected with the vendor are like, etc. In further steps you will attempt to **verify such information; you will actually expect the vendors themselves to substantiate the claims they make – and rightly so! The burden of proof lies upon them**. You will also want to verify if others, namely the vendor’s clients, have the same story to tell – use **references**. Again, some of the key questions – by no means all of them – may be selected for reference sources to provide feedback on.

* check team members references and carefully analyze resumes 
* don’t hesitate to go deeper than a Linkedin profile, check other platforms
* the resumes should include projects the developer worked on with technology stack and what contributions he had to the project
* don’t be afraid to ask if the team has worked together in the past and whether or not they are located in the same office
* ask about the open source contributions of developers, review their publications, presentations and past workshops. 


**Output**: a list of potential service providers with information from the initial search

**5) **Use the weighted criteria matrix to assess the vendors and shorten the vendor list

It is time now to review the information gathered and use your initial findings to **assess the service providers’ suitability to deliver the service** on you project. Assess individual vendors, as well as the teams they are ready to dedicate – against the pre-selected criteria, compare their weighted scores and decide which vendors to progress with. Ultimately, you should end up with a shorter list of the most promising candidates meant for more detailed scrutiny.

**Output**: a shortened list of potential service providers

**6) **Gather more information and re-evaluate the remaining candidates to arrive at a shortlist

Your initial search and assessment have hopefully shortened the list. With a more easily manageable list of candidates, move on to **interviews** to gather more information and/or verify what you have found out so far. For instance, suppose the service provider claim their language skills are excellent – they now have an opportunity to prove it live. You are not just buying an abstract service from a company or, at least, you will be much better off if you go beyond such a perspective. **You are recruiting a specific individual or a team of specific individuals to serve on your project – your crew. Thus interview THE individual(s) as well as THE reference sources related to the specific team and their track record.
* hold an interview with every developer in the team to check their soft-skills, especially the ability to communicate well (especially if speaking a foreign language will be necessary to communicate during the collaboration), as well as hard skills. This way, no ‘weaker’ developer can hide behind his more talkative, better-skilled colleagues
* be prepared to review their code samples, or even better, conduct pair-programming sessions with each of them
* you can also give them a test project of restricted scope and time

** The vendor’s company _en masse _may have impressive experience in your area, a rich portfolio of projects implemented and clients ready to recommend. The question is what has been your team’s contribution to it. It is also a good time to ask such a team for **code samples and application/system walk-throughs**. 
Don’t forget to check whether the projects the company has worked on overlaps with your project type and size. Also, consider the vendor’s size, if there are enough people to take over. Remember that bigger doesn’t necessarily mean better. If you decide on a large company you may experience frequent staff swapping, so be prepared for that. While talking to the vendor, make sure that your team will consist of both senior and junior developers.
An additional, more practical factor, you should take into consideration is the time difference between you and the outsourcing company. A couple of your working hours should overlap to avoid early morning or late night meetings, so if you don’t have a preference from which country your partner should come from, time zones may make it a bit easier for you to narrow down your search.

With the new information at hand, re-assess the remaining vendors and further shorten the list or select the best candidate to deliver the service (if you do not intend to use the steps below).

**Output**: a list of 2-3 shortlisted vendors / the vendor selected

**7) Visit the shortlisted service providers**

When the project is mission-critical, it is highly advisable to consider **an on-site visit** to gather and verify even more information on the shortlisted candidates / the vendor selected. It is obviously much easier when you intend to collaborate with an onshore or nearshore service provider, and it is much more convenient when the shortlisted candidates are located in the same geographical region / country. With the additional information gathered during the visit you can re-evaluate the remaining candidates and select the most promising vendor. You may still want to keep in touch with the other shortlisted providers though. If – for whatever reason – you fail to complete negotiations with the top candidate, you will have the others to go back to.

**Output**: the vendor selected

**8) Use a pilot project**

[Selleo](https://www.selleo.com/)’s prospects / clients vary greatly with reference to the practice. Those from Germany, for example, have applied the practice invariably. Clients from other geographic locations have been less consistent. Whenever possible, I strongly recommend the practice as it provides you with an invaluable opportunity to **test the vendor’s ability to deliver on their promises**. The development team can now prove many of the claims they made in the previous stages of the sales process. A pilot project also helps to “smooth things out” / “get things up and running” (e.g. communication, collaboration practices, etc.) before the actual work on the project starts rather than during the process. Should the team fail to meet the expectations created earlier, you have a list of other shortlisted candidates to return to.

**Output**:  the vendor selected

If at any stage you are dissatisfied with the results, i.e., you feel none of the identified candidates seems able to deliver successfully on your project, do not hesitate to go back and broaden your search at **point 3**. If you become satisfied with mediocre findings you may have to accept mediocre service delivery.

## **Conclusion**

As you can see there is quite a lot of things to be done. You can manage the process yourself or use a sourcing agent / broker to support you in the process.  Whichever way you choose, the process requires resources:  time and/or money – it comes at a very tangible cost. **What are the benefits then? You significantly reduce the risks involved in outsourcing your software development project. You increase the likelihood of selecting and building a relationship with the vendor who is actually able to deliver good service on your project.** All in all, the cost may well be considered an investment which pays off later on when you build your application. Many outsourcing entrepreneurs / firms would be better off if they had decided to account for the upfront investment.

**Post Scriptum 1 **I would like to express my gratitude to Daniel Young from [Dragon Sourcing](https://www.dragonsourcing.com/) for all the insights and useful tips he offered.

**Post Scriptum 2 **I wrote the article and compiled the lists of criteria / questions below  with the outsourcing entrepreneur / firm in mind. Still, I guess, the contents are equally important for service providers, development teams or even freelancers. What are your answers to the questions? I mean, the answers you provide in the daily practice of service delivery.

Outsourcing entrepreneurs and firms vary greatly in the way they manage the sourcing process. Some progress through it speedily and are fairly spontaneous in their approach.

How To Choose The Best Software Development Company

Let’s assume you are outsourcing your software development and wondering if things could go any faster. Development teams quite obviously vary in their inherent ability to deliver fast. On the whole, you determine the potential when you select a specific vendor / team to deliver the service. Having made the decision, you, in principle, have a very limited influence on how fast your software might potentially be developed. However, it can be observed that the very same team delivers at various speeds depending on the client they serve. The differences can often be traced back to how the outsourcing entrepreneur / company structures the collaboration process. Some outsourcers organize and manage the process well and thus empower their teams to reach their top speed. Others are much less effective in this respect. Which practices hold the development team back from achieving their top speed? How can you optimize the outsourced development process for speed? I have asked some developers for their insights and would like to share the findings in this blog post.

**1. Incomplete and/or ambiguous tech specs.**

Requirements / technical specifications delivered by outsourcers vary greatly in terms of how easy they are to execute on. We have been developing applications based on both high-level requirements and fairly detailed tech specs, i.e., complete sets of wireframes / mock-ups and user stories / use cases, which were converted into acceptance test scenarios and approved of by the Product Owner before milestone implementation. **With complete and unambiguous tech specs at hand, the development team implements much faster.**

An added advantage of providing your team with executable tech specs is that there is less need to provide them with ongoing feedback during development, which allows you to devote more time to customer-focused activities at the front-end of the product development process.

**Provide your development team with executable specs!**

**2. Tech spec development on the critical path.**

Executable tech specs do take time to develop. Sometimes they are developed only after the team have finished the implementation of a specific milestone. In such a case, developers often cannot move on immediately to implement the next milestone and are forced to fill in the gap working on a different project – an unnecessary distraction and a loss of momentum. There is a much better alternative though; tech specs can be developed concurrently with development and thus be removed from the project critical path. The development team can progress speedily from milestone to milestone.

**Get the tech specs ready for the team to progress smoothly from milestone to milestone. Eliminate gaps between iterations!**

**3. Multiple requirements changes during milestone implementation.**

Requests for change submitted during milestone implementation may slow things down. The more requests submitted and the more fundamental the changes requested, the slower the progress. Tech specs may need to be reviewed and updated, and so do the schedules and budgets (on fixed-price engagements). Rework may add onto the workload.

Mid-course corrections are unavoidable, especially on innovative projects. Still it is possible to reduce the impact by selecting the backlog items which are least likely to change as well as by reducing the iteration cycle time. With less scope on the plate, you are less likely to disrupt the implementation work to be done.

**When requirements are volatile, work on items least likely to change and shorten the milestone cycle time!**

**4. Lack of / insufficient / delayed feedback.**

**The less precise the tech specs provided, the greater the need for ongoing feedback.** When the requirements / tech specs are not complete / unambiguous, teams often get stuck in their development efforts. In such cases, their performance vitally depends on clarifications provided by the Product Owner. Clients differ in their response times – some take days, others merely hours to answer their developers’ questions and remove roadblocks which pop up on the way. Some teams take risks and develop without the feedback needed; in practice, they very often have to rework the solution when the feedback finally arrives, which again consumes time and money (on Time and Material engagements).

Knowing that your specs may be vague and you may not be available to fill in the gaps for the developers on an ongoing basis, strive for a team with expertise in your domain and application / project type. Find a team who understand your business, the problem you are trying to solve as well as the product you want to build, so that they are well positioned to fill in the gaps themselves.

**Be available to provide the team with sufficient, timely feedback. Respond fast!**

**5. Too much feedback.**

At the other extreme, there are the Product Owners who get involved despite the fact that the team have sufficiently informative tech specs against which to deliver. It does not concern cases where a scope change is needed during milestone implementation. It concerns situations where the Product Owner attempts to interact with their developers even though they do not need any feedback to progress efficiently. Specify what you need and let the team do their job.

I guess the main reason for it is that back-office activities are much less challenging than the front-end work to be done with target customers / users. If Product Owners get sufficiently involved at the front-end of the process, they hardly ever have time to waste with their development teams at the back-end.

**Do not get in the way when the team is progressing smoothly. Your time is likely best spent working with your customers and/or users!**

**6. Delayed acceptance. Team overextended on too many projects.**

Some Product Owners take a long time to check and provide feedback on the deliverables submitted by their teams. If the Product Owner unduly delays acceptance and, additionally, asks the team to progress with the work on the subsequent milestone, the team that agrees to do so, may soon be left stranded with a few unfinished milestones, which negatively impacts the service provider’s cash flow – see more on the point below. **When stuck in this way, i.e., without feedback or acceptance, teams are tempted to wait and fill in the slots with additional engagements to maintain utilization at a reasonable level. A perfect recipe for slowing things down.** If – at a point further down the road – all of their clients being served eventually decide to speed things up, they are in for an unpleasant surprise – the team may have very little room to move faster.

A note for developers. Do not yield to the temptation until after

* you have informed your client of the problem you face,
* you have presented the measures you might be forced to apply to alleviate it,
* you have clearly explained why you need to do so,
* you have given the client time to adjust, and still …
* you have been ignored by the client despite doing all of the above.

**Keep the above in mind, yet never accept deliverables which do not fulfill the agreed upon acceptance criteria**. If deliverables are flawed or incomplete, demand that the team remove any deficiencies before you accept and pay for the work done. Deliver the straightforward message as soon as possible.

**Do not delay the acceptance of deliverables which satisfy acceptance criteria. Provide fast feedback on corrections needed. Keep the team busy on your project!**

**7. Unduly delayed payment.**

From the client’s perspective, the iteration cycle technically finishes when the agreed upon deliverables have been submitted. From the vendor’s perspective, the cycle is over when the associated payments have been executed and the team have been remunerated for the work delivered. The client may have accepted deliverables and still delay the payment for them. The practice can have a very disruptive impact on the vendor’s cash flow as **typical software development houses / design agencies – like any service providers without passive recurrent revenue streams – vitally depend on the steady cash flow streams coming from the clients they serve. In the most dismal scenario, the vendor may lose valuable resources by not being able to meet their financial commitments towards their employees.** Such payment default(s) may seriously cripple the team to deliver the service, let alone deliver it fast.

Some vendors may have been stung by unfair clients who did not pay for good service in the past. Being painfully aware of the payment default risk (which increases in proportion to the amount of work delivered and not paid for), they may feel reluctant to enter a new relationship with high velocity and ramp-up fast. You can help them hedge the risk. You do not need to use upfront payment to remove the doubts besetting their minds – start off with a small job or a short iteration, let them implement it fast and clear their doubts with a prompt payment.

**Pay fast for work well done!**

**8. Middlemen**

Service providers sometimes develop applications for other software development houses operating in the client’s market rather than directly for the client who commissions a software development job. When it is so, the information flow is extended over **3-5 entities**, i.e., the offshore / nearshore service provider, the local service provider, the client and even the client’s customer and/or user. Quite expectedly, **the longer the chain, the more time it takes to develop the solution**. Just think of the number of acceptance activities to be performed and the number of people to be involved before the deliverables eventually reach the end of the development cycle.

If speed is vital, you should eliminate middlemen from the process and **be as close to the development team as possible**. You should even consider if outsourcing is the right strategy to pursue. If you optimize the project implementation strategy for speed, you may actually be better off collaborating face-to-face with physically collocated local resources. They may seem more expensive on the surface, however, if you consider the cost of delay, they may not be as costly as they appear at first sight. Alternatively, outsource but collocate with the key team members – either at your premises or theirs – for the fuzzy front-end of the process, bring things up to speed and only then – when things are running smoothly – dislocate to reap the cost benefits of outsourced development without sacrificing the speed you need.

**Eliminate middlemen!**

### **Conclusion**

If you want to optimize the outsourced development process for speed, it may well be a good idea to focus on the main obstacles which slow development down; ensure smooth progress by proactively removing the stumbling blocks which get in the way. Let’s reiterate the main points with **a checklist**:

* provide your development team with executable specs
* get the specs ready for the team to progress smoothly from iteration to iteration; eliminate gaps between milestones
* keep the team busy on your project
* when requirements are volatile, work on items least likely to change and shorten the iteration cycle time
* be available to provide your developers with sufficient and timely feedback
* do not get in the way when the team progresses smoothly with implementation
* when milestone deliverables are submitted for acceptance, provide fast feedback on corrections / modifications needed
* do not delay the acceptance of deliverables which satisfy the acceptance criteria
* pay promptly for work well done
* avoid middlemen

All in all, if you are truly after speed, release the brake and you may find out the accelerator will take care of itself.

**PS**

The article is based on the accounts and feedback gathered from my [co-workers in Selleo](https://selleo.com/people/) as well as from developers I’ve met at technology-focused events I attended over the last few years. I would like to express my gratitude for all the insights these folks provided me with.

Let’s assume you are outsourcing your software development and wondering if things could go any faster. Development teams quite obviously vary in their inherent ability to deliver fast. On the whole, you determine the potential when you select a specific vendor / team to deliver the service.

Read our articles on Selleo Blog

Business

Technology

3 Reasons Why You Should Use Time And Materials Pricing Model For Software Outsourcing

Key Players In Outsourced Software Product Development

How To Choose The Best Software Development Company

Tips On How To Optimize Outsourced Software Development For Speed

Tell us about your project