Different approaches to procurement tech implementation

Previously, we’ve discussed the typical stages of a digital transformation.  In this next post, let’s talk through some of the different implementation approaches and their pros and cons, e.g. waterfall, agile, etc.  

When to choose Agile vs. Waterfall 

The most important determining factor of whether you choose an agile versus waterfall approach is really based upon how your organisation runs a project, or how culturally you run these things. 

Source: Planview

If your organisation operates in a waterfall manner, we strongly recommend you stick with that. It is highly risky to conduct a digital transformation at the same time as trying to adopt a new methodology. 

However, if you are going to run the transformation primarily with internal resources and you do have the correct expertise, you may wish to consider using an agile approach because with the iterative nature that the agile approach brings, you can be seeking value as early as possible. 

If you are choosing a service provider for your implementation, you may consider using a waterfall implementation because you're not going to be involved with a lot of software development activities, and this scenario works well if team members (from your organisation) that you have selected to implement this project also have their operational day-to-day job, which can have a higher operational priority. 

Even if you are determined to run the project as a waterfall from your organisation perspective, you do want to ask your provider how their development team runs. Are they an agile practice or not? Because this is an indicator of how frequently you’re going to get your product updates once you have deployed the solution and once you start using it operationally. 

Agile methodology 

Now one of the major pros with agile is obviously that flexibility that it can provide and to your organisation and the ability to adapt to changing circumstances. 

As mentioned earlier, the iterative nature reduces the risk of the business because the only way to mitigate all these unknown risks is to deliver something, because the unknown becomes known. 

And the agile approach with the frequent delivery of features, the output should be able to remove that uncertainty as you’re iteratively getting some of the delivery from the output of the project. 

The cons with agile is that it requires a very disciplined and competent team to perform well. And we see a lot of agile teams struggle because it also requires a different way of design thinking. For example, how do you split iterations and how to do your iterations in a vertical manner? 

As an example, if you're trying to build a self-driving car, you will not split your iterations based on the components - for example, your engine, your traction system, your steering - because you can complete your engine in a number of iterations, but it's very difficult to realise the benefit directly just based on the engine or the wheels or steering etc. 

Source: Landmark Dividend 

However, a competent agile team would split their iteration based on functionality, e.g. Lane Departure, Lane Tracking, radar system, adaptive cruise control, emergency auto breaking. 

As this iteration begins to deliver, you can test it as an end user of gaining the benefit, and the combination of each of this delivery would tangibly move you closer to a self-driving car.  

This is a fundamental change in how you think of splitting up the task and that's why a competent agile team will be able to do this quite well in their design thinking.  

This way of thinking is so fundamental that's why it could be that certain organisation - the agile metrics like the burndown charts and the story points delivery - may on numbers work well, but the end result to the business may still be disappointing because there may be a disconnect between what is being delivered from an agile approach versus the actual business value. 

If you do want to proceed with an agile approach, you do need some good practitioners who can make the connection between the commercial value, i.e. having the adaptive cruise control and the technical development so that they could see it and point them to the right direction. 

Waterfall methodology 

It is a lot simpler to explain, and for most people waterfall approach is a lot easier to understand. A majority of people understand milestone timelines, specific dates rather than iteration. Having a waterfall model, a certain task would be projected to finish on specific time frame, which is a lot easier to understand. 

Also, typical waterfall project methodology such as PRINCE2 or PMBOK have a lot of artifacts that would be produced as part of the implementation and for some managers, which gives some reassurance, and they see a lot of values from the artifacts. 

Project management artefacts. Source: PM People

The disadvantage of the waterfall approach is of course the risk of unknown. Unlike agile, in a lot of waterfall projects, you actually don't really see what you're building towards the tail end of the project and because sometimes the waterfall project could be quite long and that increases the risk of unknown. 

(If you're choosing a service provider and given there's a lot of software development activities that you don't need to do, the time frame will be a lot shorter and in that case, that risk of unknown is a lot shorter simply because of the fact that you're choosing a software provider and a lot of their unknown is actually known, so the risk of unknown applies if you're trying to develop your own software.) 

About the change control process with a waterfall methodology: If you run change control correctly, it should have some gates, which is a good thing.  

You don't want scope creep on one hand, but the opposite side of the coin is sometimes these processes may discourage the change that would otherwise be essential for the success of the project.  

That's why sometimes the deliverable at the end of a waterfall project, while conforming to the specification, may not be fit for purpose, because: 

• Some of the early assumption may be inaccurate  
• Sometimes people might find going through the change control process far too hard or too cumbersome, which discourages the team to raise changes as part of that process  
• Sometimes the project manager running a waterfall project may be so fixated with the deadline and with any change, he would need to move some levers in regard to one of the three triple constraints of either time, cost or quality metrics. Some project managers are very concerned about moving any of these and effectively discourage them from making the necessary change. 

Build vs. Buy software purchase decision 

There’s always a discussion on whether to have a piece of software built in-house - developing yourselves - versus getting a provider to provide the solution. 

Build your own 

Having your own development team means that you have complete control of your own destiny and a final solution. It's like you're going to have a tailor-made garment that would fit your organisation perfectly - assuming that the tailor is competent - therefore, you potentially need to do less to look good in whatever clothing that the tailor is making. 

On the contrary, if you're going with a provider who has a ready-made solution, it's like you go out to a shop to buy ready-made clothes, the cutting will not be perfect. 

In my case, I actually need to think about exercising so I could look good with a standardised piece of garment. This is where you probably would be expected to spend some effort and adapt some of your processes so that they would fit how the solution would most optimally operate. 

Anyone would also know that anything that is custom made or tailor-made would require more effort. It's just a matter of fact and that, in turn, will bear the additional risk as part of that development process. 

And more importantly, now you control the entire technology stack, that also means that you have more responsibility to look after the stack.  

You have more capital investment. You have more responsibility to make sure that the infrastructure operates correctly, the correct information security is applied, which may or may not be your organisation’s expertise. (Say if your main business is construction – building bridges, building tunnels or building buildings - these kind of technology operations may not be the primary expertise that you have.) 

You also have to worry about that ongoing maintenance of the solution because if you develop internally, you need to question:  

• Who is going to maintain that ongoing and where it requires software updates, security updates and sometimes, feature update?  
• 3-4 years down the track and if you need further functionality, things have changed - do you still have the team that originally developed supporting you?  

Buy an existing solution 

Now moving from building your own, most likely you'll be looking for a Software as a Service (SaaS) provider. 

It is a radical solution, so it's more like you go and shop for a car, so there will be a lot of providers and different brands. It would perform slightly differently to each other, more or less covering the same thing which is hopefully getting you from A to B. 

That means it's less risk during the implementation because you're not building the car yourself - and most features and functionalities should be well understood. Again, like going into a dealership, you would be able to examine all the bells and whistles of each model of the car that you are having, and your focus would be primarily over configuration and the business process - how you're going to operate that car in your particular scenario - and examine how the features suits you. 

For example, if you have a lot of grocery and you happen to go and look at a Tesla, then you’ll know that you have a lot of trunk space both at the back end and the front, that would be something that score high if that is what you require.  

What that means is during that journey, there is a lot less technical burden on your team, you do not need IT, and IT doesn't really need to be involved heavily across the process. 

You still need the IT input from a strategic and information security point of view, but unlike something that you develop on your own, there's a lot less to worry about from a technology perspective because the heavy lifting is already done for you. 

Source: Avsystem

With SaaS, a good provider would be responsible for the maintenance and regular updates to the platform. The other advantage is gaining additional insights you would otherwise not have because your SaaS provider would quite likely to be working with multiple organisations across different sectors and they would have ideas and requirements that you may not have thought of previously. 

This learning in the product development lifecycle would likely give you a better solution overall because of the more diverse feedback versus feedback within your own organisation. 

Of course, the disadvantage of going with a provider is that it may not 100% fit. So, if I'm going to buy a very nice designer piece of fashion then I might actually need to do some work to make sure that I do look good with a very expensive piece of suit. 

Finally, the great advantage with SaaS is you don't need to worry about the day-to-day operation of the infrastructure and the platform. And there's also the flip side of the coin. You would have less influence to determine things like the frequency of backup and sometimes other operational processes. 

Because your provider usually, for scalability and economies of scale purposes, will have a standardised way of managing these things, and they should be able to provide you with SLAs and how they operate those activities, and you should review them - those standard regime - and see if they match your requirements and you are satisfied with that. 

Source: Techtarget

Effectively in most cases, most competent SaaS provider would be able to give you a comfortable level of operations. After all, they are the technologies company, that's their primary job and you shouldn't need to worry about it, and you should focus on the primary activities if you're building things or if you are mining things and so on.  

---

In summary, the great thing as we know about SaaS is it's never finished and the customer of a SaaS platform gets all the upgrades, gets all the enhancements, gets the Dev team working on it, and the product team looking at customer feedback and industry feedback and improving all the time.  

Whereas if you go down the build your own approach, often an internal development team is given a project and as soon as it's finished, it's finished. You're moving on to the next thing, and all of a sudden that technology becomes old very quickly. 

--- 

Stay tuned for the next part where we’ll discuss common bottlenecks during implementation, and how to overcome them.  

---- 

Watch the full webinar Tips for Successful Procurement Tech Implementation.