The text below has been anonymised. The exact names of people and companies are irrelevant. The blog is written to share lessons learned.

In part 1 of this blog series, we explained what happened after Jan’s “cry for help”, and Jan’s company. For those who missed that, see https://m2-d2.com/en/can-you-take-over-part-1/. In part 2 we picked up thread again. The platform had gone live and there were more than eighty change requests. See https://m2-d2.com/en/can-you-take-over-part-2/. In this 3rd and last part we answer 2 questions: would we do it again tomorrow? And if so, would we approach it differently?

Okay, straight to the point: would we do it again tomorrow?

Yes absolutely. There’s a mess, someone needs help, and we’ll fix it. That’s just a nice role. A bit of a “hero role” 🙂 And no, we are not afraid of someone else’s spaghetti code, because we just improve it step by step. We are not afraid of customers who are not experienced IT people, who need a lot of explanation of why and how something works the way it should work. That’s our job, we’re good at it and we think it’s great fun.

Would we do things differently tomorrow? Yes, in parts.

For example, we would create the UAT environment even faster in order to make it clear to the customer, i.e. the user, that they are responsible for testing, for approving whether we have created also meets their wishes. Precisely because those wishes are not always clearly formulated in advance, and you don’t want to find out in production that things are different than you had envisioned.

For example, next time we would spend even more time, at the beginning of the collaboration, on making expectations explicit and in our case explaining the working method. Especially if the customer does not realize what has happened to him in the past. is not a “Wordpress front” but a Python/Django based front-end application (and a back-end application).

For example, next time we would spend more time, at the start of the collaboration, to document the existing functionality and therefore operation. Not in the sense of writing extensive documentation or something like that, but, for example, using video clips of all screens, all clicks on all buttons, and all reports. That baseline will help to avoid unintentional misunderstandings about “that was already in it, wasn’t it?” and “didn’t that work well in the past?”.

For example, next time we would spend more time giving a verbal explanation of the weekly report. Every Saturday, Jan and his people received an update of the activities and results of the past week. Of the status of the sprint and therefore of the planned activities for the coming week or weeks. Plus a proposal for the implementation of the sprint afterwards. In about 5 to 10 slides. But … it helps to go through that with each other on Monday morning, experience shows. That takes half an hour to an hour, but it helps enormously to let the customer climb into his role and to understand where he should focus on steering.

And we would like to define the division of roles on the customer side even more clearly next time. Maybe even have it signed “with blood” 🙂 Because that was still one thing with Jan and his company. After the prioritization workshop, we thought it was clear which tickets we were going to pick up and when. E.g. making a number of fields to be completed by the end user mandatory. A small change, but still. We then delivered that change, it was approved, it went to production and a week later Jan came on the air with “no, that’s nonsense, we don’t want that, we’re not going to make that mandatory”. To which I explained somewhat flabbergasted that in the workshop we really … and they really are functional managers … but no, Jan had thought otherwise. No problem, we will adjust, but that will be extra costs for Jan. This leads to a discussion about which no one is happy about. Hence: setting very clear responsibilities, and keep insisting on that, so that the customer knows that if he gives his functional manager the responsibility to manage us …

Today we are wiser than yesterday. Nice. Perhaps that is the definition of work, and life for that matter. And so I say to anyone who is arguing with or dissatisfied with the software development and operations management of their current IT provider… need help? Call us! That’s our profession, we’re good at it and we think it’s great fun!