Supplier Evaluation for Agile Projects
Updated: Jan 12, 2020
Evaluate your supplier for agile projects based on the below criteria
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
functional and non-functional requirements and
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.