My name is Hayden, I’m a partner in HopgoodGanim’s Intellectual Property and Technology Division. HopgoodGanim is a national law firm. My practice generally comprises of advising clients on intellectual property issues both in terms of protection, commercialisation and enforcement. As well as looking at information technology, procurement agreements, licensing, SaaS-based arrangements, and informational privacy risk.
I think it’s a really good practice for both parties both on the vendor side of things and on the customer side of things, to make sure that a non disclosure agreement is in place. The reason being is that the customers going to want to talk freely to the vendor. To make sure that they can say these are the strategic directions I want to take my business, and this how I see your solution or your service being able to fit within that. That strategic information has a value and that needs to be protected via obligations of confidence. As well likewise for the vendors perspective, they’re going to be disclosing things like pricing information, things like licensing structures, and from their side things they may not want that information being generally out there in the public. So it’s in both parties interest to have a simple, short, non disclosure confidentiality agreement in place just to set the scenes so that both parties can openly communicate with each other, without feeling worried that one’s gonna do or tell something about someone that they shouldn’t.
I suppose agile has a traditional meaning in terms of a project management methodology in terms of IT procurement. So I guess it could be contrasted against to the traditional waterfall method of IT procurement. Where parties go through a formal stage to make sure that the requirements from the solutions are mapped out formally. Each one of those requirements is sort of a implemented on a stage based arrangement and tested incrementally before being accepted and before moving on to the next stage.
Whilst the waterfall model I guess is something that is appropriate for some projects. A lot of the time in practice it’s never properly adhered to so contractual arrangements which reflect that waterfall model often aren’t meeting the reality of how customers and vendors engage with one another. So then turning to agile based procurement and agile based project management, we’re looking into a more free and open way in which the scope and the requirements are incrementally determined, incrementally found out as you go where subject to less fixed structures, often it enables parties to better determine what the requirements are for the customer, which is ultimately what the customer wants. They want a solution that meets their requirements and when they first engage a vendor for a solution they may not actually know what they need, that is only determined as you go. So if you’re locked into a solution right at the start before you actually even know what the shape of the solution is and their fee mechanism for the whole contractor is locked into that, it’s really inflexible.
When we’re looking at the agile based solutions still some structure. There’s still I guess an arrangement where both parties have requirements. The vendor goes and tries to meet those particular requirements. It’s just tested and feedback is given in a more continuous loop in a more dynamic way. And in my experience a lot of the time it can result in better outcomes for the customer.
The biggest thing I’m still seeing in the recent years is the transition away from old models of IT procurement where on-premise solution and the customer is responsible for hosting and running that particular solution more to as a service type cloud based model procurement. Simply because again from the customer’s perspective they’re in the business of doing something, it might be running a set of franchise based restaurant outlets or something like that. That might be what they do and they do that excellently. At the same time, maybe what they don’t do is actually host particular niche areas of software based solutions that may not be their core business, so that makes sense to outsource that particular aspect of their business to obtain it as a service.
They don’t have to worry about things like installing updates within their architectural within their own customer infrastructure. You guys as the vendor manage all of that for me takes that pain away. And also, at the end of it all if whatever reason you don’t like this solution or you wanna look to something different. You know I guess wedded to some particular solution that’s embedded within your whole infrastructure. You’re just acquiring it as a service, you get the data or you go on and deal with the next service provider. So it’s a lot more of a dynamic way of dealing with a vendor and often the customer sees a greater benefit because of that. And it ends up often being cheaper because you know,you are paying as you go as a service and not subject to a big upfront capital expenditure associated with an on-premise based solution.
I think the real control that it gives them, is it enables them to I guess control the shape of the solutions they go. As I said before, customers often have an idea of what they want at the start but maybe once they’re working with you the vendor, on a solution. They might think actually what I thought was a good way of doing things could actually be done way better or way cheaper. So working under an agile basis enables both parties to get benefit of that. And at the end of the day you might get a more elegant, more efficient solution as a result.