In this episode of IT Leadership Insights, our expert, Janne Marie Van Vlastuin explains how governance procedures can prevent IT projects from failing.
There are a lot of things you need to consider before starting a software development project. So, what can you do to be sure you don’t overlook anything? How to define the roles and responsibilities in the customer-supplier relation? How to manage the cooperation to make it as seamless as possible? You’ll find all the answers in this very episode.
Janne Marie will also reveal why it is sometimes good to go outside the price, scope and quality factors of your agreement and focus on the soft side of business partnership.
Our Guests:
Janne Marie van Vlastuin is the Co-founder of 10DED who support organisations in humanising technology, both ways. They do this by helping leaders and organisations transform in becoming ready for the digital era in a pragmatic and understandable way. Janne Marie has a unique combination of hands-on experience as a leader in Sales, Marketing, Service, IT and HR, combined with extensive knowledge and experience of best practices, change management and various methodologies. This enables her to speak all the languages needed to get organisations moving and providing them with the right tools and frameworks in the right way. She is different, but this has made her a successful expert in transformational programs within the commercial domain. Janne Marie was nominated as the Most Innovative Leader 2017 by the CIO magazine in the Netherlands.
Michał Grela is Future Processing’s Relationship Manager, working within the marketing department to establish and nurture relationships with prospective customers and expand the company’s network of contacts. He strongly believes that business is about people and that, at the end of the day, it’s all about Human-to-Human rather than Business-to-Business.
The transcript of the episode
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 proxy of this Product Owner or Project Manager?
JMvV: I prefer to let developers be developers, not communicate on a daily basis. But just let them do that, if its clear, the assignment is clear, that they can just do their work because if you’re really, that’s my own experience, some consultants, so if you have more functional consultants and developers on that role, they should be allowed to ask ad hoc questions but they also prefer just to configure the system and in development, if you talk to those, to those guys, they just want to make beautiful things. So, communication doesn’t really bring them extra because it takes, if you look at the amount of hours, it takes to make a functional design out of a requirement, so two hours for requirements, so, six hours functional design and then look at the bill, that 18 hours. Let those 18 hours be 18 hours.
MG: Okay, so, is it even possible to implement KPI’s or measure such intangible things as as relations?
JMvV: It is possible. Of course, satisfaction is one. But what’s even better is ask your customer about how his definition of successful relationship is and then tell your definition of a successful relation and the start measuring up on those.
MG: It’s rather a partnership approach.
JMvV: Yes, because very relationship has both sides that have to get something out of it, which is called a partnership. And in the ideal situation, you go outside of the price of your agreements and the quality agreements and actually go one level deeper to see what kind of value you can add to each other on top of that. And measure that as well. So, let alone from the hard things on rework, tight budgets,
MG: That can be a KPI.
JMvV: Yeah, exactly. or time budgets, was it or, or the scope, original scope, how happy was the business looking at the acceptance criteria and the approvals. So, there are different things you can measure but if you talk about relationship, then you also have to put effort in the soft.
MG: Yeah, so you can stick with hard KPI’s but it’s best to go with the soft partnership or combine both approaches. That’s thoughtful. So, were you to give your best tip of IT governance and maximizing efficiency of this relation, what would that be? Like few best tips.
JMvV: I think make roles and responsibilities very clear. Understand what a customer-supplier relationship is but also the real customer is. And the real customer is the end user. So, put that in the chain, because IT itself is an internal supplier working together with an external supplier. And, at the end of the day, understand that working together is about making clear agreements but mostly about trust. So, if you have a good relationship, you can bring much more value than if your relationship is based on procedures only because that is really an impossible way of really working together. But also make those agreements that are fit with your culture and find that company that really clicks with you. There’s this alignment – as a culture, so, because at the end of the day, it’s all about communication. Even assumptions, not taking assumptions and having a low barrier into finding answers. It’s about communications. So, if you do not communicate in the same way as your customer does or your supplier does, then it’s very difficult to build that bridge of trust and to move things.
Just not speaking the same language. So, I think that selecting your supplier upon that is key.
MG: Yeah, and at the end of the day, if you end up working with who are more or less similar to you then, well, even hard work can be fun. That’s my perspective.
JMvV: Work should be fun.
MG: I really like this bit about trust and partnership. Thank you for that.
JMvV: You’re welcome.
MG: Thank you for this conversation. It was very very thoughtful for me. Thank you. It’s a great pleasure having you. And thank you our viewers for watching this episode of IT Leadership Insights by Future Processing. If you have found it useful, please don’t hesitate to share it and like it. And please do drop us a line if you would like to have a topic covered in one of the future episodes. Thank you.