Michał Grela (MG): Hi, my name is Michał Grela and this is IT Leadership Insights by Future Processing. This episode is about IT governance. Research shows that IT project fail mostly because of human and managerial factors. In fact, these managerial and human issues are accountable for 65% of IT project failures. Whereas, these technology issues stand behind only 45% of reasons or failures. In order to maximize effectiveness of development, you have to have governance processes and procedures in place that will enable you to measure performance and monitor this relation with your software development partner. Today, my guest is Janne Marie van Vlastuin, experienced Business Transformation Consultant. I’m going to ask Janne Marie what IT governance is about, why do you need such processes and procedures and whether is it even possible to monitor such intangible things as this relation between a supplier and buyer? But first things first, a quick introduction Janne Marie. What’s your background?

Janne Marie van Vlastuin (JMvV): Well, I’m an organizational, I studied Public Administrations Specialized Organizational Science and Macroeconomics. And after I, well, my study, I decided to start developing software, because, designing software because all innovation and economical growth is being driven by innovation and technology. And at the end of the day has to land in technology. So, I wanted to be able to change an organization from A to C and understand everything completely. And I specialize in the commercial domain so, sales, marketing, which I also had leadership roles in. So, I’ve been doing that for 12 years now. And currently the past years, I’ve been doing larger transformation programs with multimillion budgets.

MG: Right, that’s impressive. It’s a great pleasure to have you here.

JMvV: Thank you for having me.

MG: Getting back to the topic of this conversation, IT governance, how do you understand it? What does it mean to you?

JMvV: For me, governance, not only IT governance, but all governance is just a clear description of roles and responsibilities that you know who is allowed to determine what even before you start. If you don’t have formalized governance, then things become a mess because it’s unclear who has to decide what and ownership is usually one of the biggest hurdles or bottlenecks because when things become difficult, people tend to let the ownership lay at the other party and not with themselves.

MG: Okay, but is governance a strict thing and you have to go by the book all the time? Or is it something that is dependent on given situations, circumstances?

JMvV: I have to say that there is not a book about governance so, really depending on the organization and the relationship you have and also the type of governance and if you take, for example, the IT and supplier governance relationship, also there, it is very much depending on how the organization, how the functions are being put in the organization and where it should be because sometimes it should be in the alignment role. Sometimes it should be the IT departments that has the direct link with the supplier or vendor. And sometimes, even the business.

MG: And what about issues such as the culture of each organization or the the maturity level of each of them?

JMvV: If you look at how you implement the processes, you have for example, a very nice best practices like ITIL or by BSL, which I really like myself in this new day and age. If you take that strictly, I’ve seen this one program and that was years ago where there was this one company, I’m sorry, I’m laughing, which implemented both ASL, the three ones, ASL, BSL and and ITIL all in different departments.

So, at the end of the day, there was no governance but they implemented three best practices so, it should work. But, that’s not how it’s supposed to be done. You take a best practice as a frame and then you apply it to how your organization is functioning and communicating.

MG: So, the alignment is key but you’ve also mentioned procedures. What procedures do you have in mind? What procedures should be in place?

JMvV: For example, quality procedures and so, talking about the acceptance of work. So, we’re talking about rough development work but also on configuration and if you talk about SaaS solutions, you should talk about the acceptance criteria from a business perspective when delivering. So, if you look at the definition of success of a project, it’s usually how the business perceives it and how things are being used. So, when you know from the requirements you’re gathering, what are the critical factors which the business will accept your solution upon those are your acceptance criteria. Those should be user acceptance criteria. I’m so glad you brought that up.

Same as with your functional, development function design. The functional acceptance test should be performed based on those criteria. And there should not be functional testing being done in the user acceptance test because everybody’s responsible for their own level of requirements. Same with the technical solution design. Based on that design, technical testing, regression testing and it all should be done. So, and it’s depending on the type of development and it impacts what kind of testing you’re doing. But it’s better to also define those procedures in advance than ‘I’ll think of that on the spot’ and I see that, there are a lot of companies missing those old fashioned quality criteria.

MG: All right, so you should focus on the quality at the very very early stage.

JMvV: Yes.

MG: And have the acceptance criteria ready and have them as your requirements in front of you.

JMvV: Yeah. They are your requirements.

MG: That’s very interesting. But I guess that can be a hard process for many. So what are the common mistakes you have seen?

JMvV: Usually, there’s a problem, people already think that they know the solution. They go to their partner and say: ‘We need a solution’.

And instead of taking the time to actually go deeper to understand what really the problem is or actually letting your partner ask questions about the problem. And then they say: ‘We want this and that and that’ And then when it’s delivered:’No that’s not what we needed’ ‘No, but that’s what you asked for’ And that is because they skip the first phase of really defining the assignment rights and aligning that with your supplier, with their supplier in a proper way. So, instead of asking a solution for a problem, they’re only asking for a solution.

MG: Well, I couldn’t agree with you more. That’s a very common mistake and what I also observe is that people instead of asking, they just take assumptions.

JMvV: And that is a, if I may be so rude, assumption is the mother of all f*#k ups and this really accounts for IT development projects.

MG: It really does.

JMvV: I always tell everyone that has to do an analysis, pretend you’re from Mars, that you’ve never walked around this planet and ask for everything. To give you an example, I’ve done this program in Ethiopia. There was this really nice solution where you could see on a map where the customers were. It would have been built like that if it wasn’t for asking are people in that team able to read maps?
Because they are not trained like we are to read maps for direction. That’s not in their upbringing. So, if that was just gone through, they would have had a solution

MG: Interesting example.

JMvV: – which they were not able to work with. So, you have to really pretend you’re from Mars and look for what the problem is and find the solution that fits with the people you’re working with and really solve that problem.

MG: Getting back to more of a higher level of of this topic, who should be responsible for managing this relation like in general people-wise, who should be involved in in this relation managing?

JMvV: You mean the the supplier

MG: – Buyer relation.

JMvV: That is also depending on the type of organization because if you have a larger organization, you usually have a Delivery Manager on the side of the the supplier and you have a Contract Manager on the side of the customer and they do most of the discussions. If you have a strategic relationship, it should be more on a board level. They types of programs I do, I usually have two levels because I have projects, so I run several projects. And then I have a program board. So, the strategic relation, I have managed in my program board so, One of the board members who was the sponsor has to be in direct contact with the board member of the supplier and then in the projects, I want to have a Customer Success Manager, or have a senior dedicated Account Manager to represent the supplier and have direct contact with the Business Program Manager who represents the business who is an extension of the local sponsor. So, this is how I usually make sure that relationships are managed on both levels.

MG: And on project level, what about the Product Owner? How do you usually sort that out?

JMvV: I usually let the Product Owner, if you talk about the development team, the Product Owner is the only one to issue and change requirements towards the delivery team. And I have the Business Project Manager to do all the coordination and the discussions.

MG: Okay, so then do both?

JMvV: I have two different roles and they’re never allowed to be the same person.

MG: And what about the development team? Do you rather like to have them being involved in daily communication or do you like to rather have a