Agile Forest

With the rise of more and more organisations moving towards using Software as a Service (SaaS) and Commercial Off The Shelf (COTS) solutions for their product problems there is a gap in understanding about what Agile can offer in this space.

Most believe that Agile firmly just sits with the actual development of the product and stops there. Today, I will be arguing that there is more and will solely focus on the non product development aspects.

To do this I need to delve a little into the procurement process of choosing a product, but keep in mind that each organisation will have it’s own process. What I will describe is just a method, there will be others, but it is one approach.

So to start let’s go back to basics. You don’t just wake up one day and say “Hey let’s use Product X for our flagship Y!”, unless of course someone high up within your organisation got a free trip to a fab place by a vendor who remains nameless.  You likely have a core need for such a product/service. Maybe your existing system is on green screens. Maybe your business has changed so significantly that you current solution isn’t anywhere close to your needs. Whatever is the reason you need to be clear what the problem is you are solving before looking at what could solve it.

Once you understand your problem think about the needs of the product/service. These are your goals not your requirements.

I believe that it may be at this point in time that you first want to entertain the idea of a COTS/SaaS solution. Normally I believe this would be too early but if you are going down the path of not custom building a solution then you are essence entertaining the idea that you may be dramatically changing your business process model. Now, just as a point, I want to clarify that when I am talking about COTS or SaaS I am not talking about Google docs or GMail, I am talking about software that makes a difference to your business on a day to day basis. It could be a new accounting system or a complete HR package solution. In these instances it is likely that you already have a complicated set of business rules that is embedded to your culture. It is likely that the existing product is so tied to behaviour and process that where one ends and where the other begins is no longer understood.

When you choose to use a COTS or SaaS solution you throw away your business process and use the product/service’s process.

It might be important to you to understand the deviation between your current process versus the product/service’s process via a gap analysis so that you can work out the impact from a re-training perspective, but I believe that it is waste – regardless you will have to retrain or hopefully you will chose a solution that is so intuitive your seven year old could use it.

Next you need to understand your desires for the new product/service. These are your detailed desires – but they should not be thought of as requirements as it is highly unlikely that a single product or service will meet all of your desires.

Categorize your desires into three levels – absolutely critical (showstopper if product doesn’t have), would be elated if it had/did, would be nice if it had/did.

Do these sessions in the same way you would do all of your Agile work – in collaborate teams.

Kick-off your procurement process using the categorized desires as feeder items. Rate the products/services based upon these categorized desires. Naturally you will rate them on other procurement factors such as organisational stability, reputation, service levels, etc.

For the three products/services that score the highest on your ratings invite them into a collaborate workshop (not at the same time, separately). Run this in an Agile way and assess how much they are adaptable to the way you are working. Get them to help you break the desires down into real implementable stories. Estimate the stories with their help. Some stories will cost nothing to implement as it will work out of the box, but a lot of the stories will likely require some element of configuration or data gathering and analysis.  When you are estimating consider any interface implications, configuration, customization (strongly not recommended to do this), data gathering, data analysis, legal checks, policy checks and the number of stakeholders that you might need answers from.

Then with the product/service vendor also break down and estimate stories for training, communications, culture and business process change management, deployments, environments and extent of testing. If the provider will be offsite add in additional costs for communication (an additional 10% in accordance with the Thomas Allen curve).

Prioritise all the stories. You can now compare the plans and costs between each of the vendors with an understanding of the cost of the product/service itself. Chose a provider and continue with your procurement process.

When you start to write all these stories up it should become very obvious that implementing a COTS/SaaS solution isn’t as easy or cheap as expected. In fact, it is highly likely that the product/service itself is just 25% of the overall costs. This is something that the people with the buying power often overlook. It is everyone’s responsibility to make sure the real cost comes out and is understood.