Supplier Evaluation for Agile Projects

Updated: Jan 12, 2020

Evaluate your supplier for agile projects based on the below criteria

Image of a toy polar bear (left) and a spotted dog (right)
Which one would you pick?

Are you looking for the right partner for designing, building and operating a software application? Do you want the application to be developed iteratively? If so, then you are about to conduct a supplier evaluation for agile projects.


You need to make sure that your team's decision for a specific supplier is based on


  • strategic

  • financial

  • functional and non-functional requirements and

  • operational


considerations. But this alone is not enough, since agile methodologies require close collaboration between the customer and the supplier.


Making the Right Call for Agility


In an agile setting, your team will look for a supplier that will help it build and maintain the application in an iterative manner that maximises business value. Obviously, this requires your supplier to not only understand agile methodologies, but to also be capable of applying them to your specific setup.


Moreover, frequent and direct communication between your stakeholders, your team and the supplier implies that the latter is not acting as a service provider, but as a partner. So the first and, in my opinion, most relevant step is the following: conduct a joint working session with all of the above in order to find out whether your supplier is indeed a partner and not just a service provider.


Evaluating Your Potential Partner


What do you need to take into account when conducting a supplier evaluation for agile projects? In the following, we will briefly elaborate on the considerations given in the introduction.


Strategy: Always Good to Have One


When it comes to choosing potential partners, it pays off to have an overall strategy. A common approach is to maintain a supplier portfolio and assign a strategic value to them. Your team could, for instance, classify suppliers into an invest, de-invest and maintain valuation, quite similar to recommendations given for stocks.


Financial: Do Not Just Focus on CAPEX


The one time capital expenditure (CAPEX) that your team makes for designing and building the application is just part of the equation. Operational expenditure (OPEX), such as license fees, maintenance fees and infrastructure operating costs, also need to be factored in.


This even applies to the case when you do not need to foot the entire bill, as is often the case in a corporate environment. Calculate the total cost of ownership (TCO) by summing up CAPEX and OPEX over a given number of years (e.g. 5 years) in order to get the whole picture for each supplier.


Requirements: Do Not Describe the Solution, but the Problem


When it comes to phrasing both your functional and non-functional requirements, you need to keep three things in mind:


  • Describe what you want and not how you want it

  • Refrain from trying to define too many details upfront

  • Elaborate the business value of each requirement


This approach helps you to come up with a list of rough requirements that span a problem space, rather than define the solution. You can additionally make sure that you compare business value in the form of a so-called forced ranking of your requirements. This will enable you to build a ranked Product Backlog of your requirements.


Do you remember the aforementioned joint working session for testing whether your supplier is a partner? Conducting a planning session for your Product Backlog together with each potential supplier is a great opportunity for this.


Operations: Eat your Own Dog Food


Hopefully rather sooner than later, your team's software application will start to be used by the people that it has been built for. As soon as someone's work is dependent on your application, you need to at least detect any occuring issues and quickly fix them. And this is even just a small part of day-to-day operations.


So, when looking for a supplier, do not forget to first define to which extent you will require his assistance in operations. It pays off to let your supplier fulfill a central role in operations, as it gives him an incentive to build a stable application that is easy to maintain and further develop. Preferably, the supplier will let you collaborate with a DevOps team that will not only build your application, but also operate it.


How Do You Become Entangled?


You probably already guessed it: when having chosen the proper supplier, he will not only work together with your team, but eventually will become part of it. Removing the boundaries between your team and your supplier will help you to react faster and better to changes and to ensure stable and sustainable operations.


Care to Know More?


In case you might be wondering: yes, that is my dog in the picture and yes, that is his toy polar bear :).


Would you also like to know more about this post's topic? If so, then please post your questions in the comments below and I will be answering them. If the subject of your question is a hot topic, then I will dedicate a post to it in the future.

22 views0 comments

Recent Posts

See All