Choosing The Right Engagement Model

PODCAST: Listen to Kareem Tawansi and Brett Raven discuss the importance of nailing the engagement model when transitioning to the Cloud

So, when engaging with the implementation partner for your Cloud transition or Digital Transformation journey, it is absolutely imperative that you get the right engagement model in place. All the goodwill in the world, all the great cultural fit, will all come unstuck if the engagement arrangement between the various parties is not optimal.

Usually, in a larger enterprise, there are 4 main interested parties:

“The business” – the group whose bottom line will be affected by the results of the project(s)

Internal IT – the group who often has ongoing ownership of all systems, including newly developed ones

Procurement – the group who must ensure that your company gets a good deal.

The (vendor) partner – the group who has to supply the deliverables (ie. A system or systems that meets the needs of The Business at a value proposition that works for Procurement and does not cause headaches for Internal IT)

Wins All Round
It’s essential that all 4 parties get a win out of the arrangement – you could kind of say that you’re looking for a “win, win, win, win”. Obviously, The Business wants to get all the features they believe will accelerate their business, whether that be for cost reduction, improved productivity or the ability to attract new and/or retain existing customers. Procurement needs to ensure that the best deal, wholistically speaking, is reached and that the client company are getting absolute value for their money. Internal IT needs to know that any new systems are not going to cause them headaches, either in the short or long term and that company-wide practices are adhered to. And finally, the deal has to be sustainably workable for the vendor partner. If this is a successful project then this will be a long-term project for all parties concerned.

Methodology
Next you need to be thinking about what style of methodology is right for your business. Generally speaking, these days Waterfall isn’t particularly popular for innovative software projects however, depending on how you business works, it might be suitable for you. And unless you’ve been under a rock for the past decade, by now you would have heard about all the “wonders” of Agile software development. Unfortunately, Agile hasn’t been as successful as the promise. And while I know the hardcore Agile enthusiasts would say that it because it isn’t usually correctly implemented, the reality is that if there’s a barrier to adoption then it may not be the holy grail it was touted to be. That brings me to the increasingly popular hybrid model, that borrows from both Waterfall and Agile.

Who Pays for What
So let’s talk about how your project will be paid for – Fixed Price, Time and Material or something else? Generally speaking, clients (and especially their Procurement folks) have a preference for Fixed Price. That is because it fits easily into a box – “you give me a set bunch of features and I will give you bags of set amounts of money”. While that is very neat it doesn’t reflect the reality of software development. There are always “unknown unknowns” and they have to be dealt with in a fair and equitable way. Fixed Price is a zero-sum game which means that one part is very likely to get a windfall and the other a shortfall. This doesn’t bode well for a long-term relationship.

The Agile camp will likely be advocating for Time and Materials. After all, with all this flexibility for creativity things may need to be built and rebuilt or even discarded and this all needs to be paid for. Now, I don’t know about you, but I’ve never met a team responsible for managing budgets that are completely comfortable with this approach.

That brings us to the 3rd and ever-increasing option, which is Target Cost (or Cost Target). Put simply, a project starts with a defined backlog of tasks against a defined budget. If there is any deviation from the task list (due to uncovering unknown unknowns or a change in thinking), variations aren’t instantly created. Instead, both parties (The Business and the vendor partner) work on descoping lesser important items so that the original budget can be maintained.

Who owns the Pain
But because we live in an imperfect world and projects often (nearly always) don’t go to plan, there needs to be a plan for dealing with this. And simply put, that plan should be Share the Pain and Share the Gain. So if there are more tasks than originally planned for, and not enough can be descoped to make way for new ones, then budgets will need to be amended. The flip side to this is that if things take longer than expected, for no logical reason, then the partner may need to wear a few things. The one thing to note here however, is that if the partner is engaged on a “Work for Hire” basis, their only opportunity to make revenue is for the time they are selling. This is unlikely the owner of the new or upgraded system(s) who could get many years of return on investment. As such, when sharing the pain, this needs to be taken into account – the outcome has to be viable for both parties in perpetuity.

As I have said many times in this article, this is about a long-term relationship that must be sustainable for both parties. Both parties need to feel they haven’t left any money on the table while also looking after the interests of the other(s). This who can master that delicate balance get to reap the rewards of a successful software development project.