Why do some people stay in a toxic relationship too long?
Why do others carry on making a living in a career that they hate just because they spent years and shedloads of money at university?
Sunk costs, that’s what.
It takes maturity and a lot of self awareness to look at that, and realise that a change is necessary, regardless of the sunk costs.
In this week’s podcast, I have a deep conversation with Mohamed Jassat (FF.ISP), Senior Director at Cognizant about his journey in the #Salesforce ecosystem from a business customer to a consultant.
He was part of a huge initiative – moving platform from Siebel to Salesforce, and shared some fascinating insights as to how to successfully maneuver this change, ensuring the people, processes and technology is aligned.
I remember this baking disaster some time ago, and tearfully munching the sad results because “I had put in the effort and it would be a waste!” 😭🍰
😱
Now Me would have gone back to time and smacked some sense into Past Me! What was the point of stuffing those junk calories that didn’t even taste good?! 😠
Anyway, I hope that you enjoy the podcast, link 👇🏻
#OnThePeiroll
Transcript
Pei Mun Lim
Hi Mo! Welcome to my podcast OnThePeiroll. How are you today?
Mo
I’m good Pei and hello to you too. Great to see you again after school. Well, God knows how many months, it’s been since I last spoke to you. I know I need to be with you.
Pei Mun Lim
And we work together. And I really, really enjoyed our time together. And it was all together to show. So I have been looking forward to this because this allows me to dive a little bit deeper into what makes Moe Moe and get to know and learn about your journey, and the things that you’ve discovered along the way. So why don’t we start with just how you got here? How did you get to this current position as senior director, he probably isn’t. And you can start wherever you want, or the inside the beginning of your sales journey or even further back. Just what are the things that happened that shaped the person that you are?
Mo
Yeah, cause? I mean, it’s a really, it’s a really good question. And I say, where do you start? I think I’ll start way back when I started my career, because it’s an interesting journey that I took into how I ended up in it. So probably, let’s start where I left college. So I had, I done sort of my A Levels. And there were a funny bunch of subjects as well. So I did economics, computer science and maths, I was pretty poor at maths, but really good economics. And computing, for some reason, strange reason, even though Peter muscles are my strong point, I’m somehow managed to, you know, be able to code and have some fun with computers. So I ended up with with these eight levels, and I had a chance to either go down to university and, you know, take a degree. And at that time, I was quite keen on a business, stroke it degree, or to start in the world of work. And, you know, start my journey straight into a career. So having sort of pondered over it. And with the family, you know, my dad being sort of an entrepreneur as well. So he’s to run a clothing manufacturing unit. So he’s to sort of supply that sort of chain stores with jeans and jackets, and all that sort of stuff. So, you know, in the family, we’ve always been used to sort of running businesses and stuff. So I ended up not going to university, but actually ended up working for a company called the British shoe Corporation. Now, if you’re as old as me, you probably recognize some of the names like true for Freeman hardy Willis, doll says. So these were all shoe shops on the high street. That’s years ago, which we don’t no longer exists, right. But there was a massive, massive company in Leicester. And they, they all you know, they had shops just about every town and village across the country. So I ended up starting with them as a retail manager, trainee retail manager on the management training program sees my set of first, currently my first job. It was a sort of 12 month program, where you ended up going into Birmingham for several months, learning the theory of management, how to manage teams, how to manage profit, how to manage stock, etc. So they trained you from scratch on how to run a large successful shoe shop. So over that sort of period of time, you got moved around to different shoe shops working under different managers, different management styles, different staff. And 12 months after that program, you ended up managing your own shoe shop, which I did. So I actually managed one not so far from Leicestershire in a small village called Ashby de la zouche which was a sort of small, small village and it had a shoe shop there. So that was my first one. And I managed to actually turn that around that shoe shop in terms of how much we used to sell from where it was within sort of 1212 months to sort of doubling the revenue. So it was a great experience for me managing my own little shop and being able to sort of prove that what I’ve learned I’ve put into practice and successful gaber manage my staff and motivate them to sell. Some people in those days that staff used to have targets as well as daily targets and stuff set up. You really convinced your customer their shoes, they were trying really great. They look fabulous and they have to have them and also we used those in those days. It’s funny funny Because you start to cross sell. So I don’t know whether you remember many years ago, when he used to go to a shoe shop there was trying to sell you some, some Polish or some spray, remember that? They still do. They still do. Yeah. So we had a separate target for that. And again, it was motivating people to actually sort of upsell, you know, from buying a pair of shoes to buying all the protectors with, as well says is, it was fun. That was that was sales for me, and I loved it. And I love sort of going for those targets. So yeah, I did that for a number of years, I move through different branches, and I managed a large branch in Leicestershire, as well. And from there, I sort of moved into another sales role with a company called macro wholesalers. So they used to basically service the trade. And, you know, people from pubs and restaurants is to come in and buy buy things I used to manage one of the departments there, which was, again, footwear and fashion. So I did that they opened up in Leicestershire did that for a number of years can similar industry, retailing, sales, and management. And from there, I sort of moved into tobacco, for some reason selling tobacco. So again, into a fairly large company called Imperial Tobacco, I think they’re the probably fourth largest tobacco manufacturer. I’ve never smoked, I haven’t smoked ever citizen, it was a bit of an odd one, going out selling cigarettes to retailers, despite the fact that I didn’t smoke. But it was again, you know, a really interesting 21 years of that one, one company 21 years, I actually stayed there. And, you know, again, the sale, I started off in a sales role selling cigarettes brands to retailers, I mean, the, the ultimate goal was to try and increase them to stock a wide range of our brands. So each time we used to visit them, we used to encourage them to actually expand the brand range, put our brands in the best place on the cigarette units, etc. So, you know, again, a very sales focused role. And, you know, did that for a number of years, when I started out with them then moved into managing a sales team of about 12 sales reps across the Midlands region. So again, bringing some of that management experience and theory learned back, you know, in the shoe business, bringing that back in again. So again, you know, went through a number of years there. So I guess this is probably now we’re getting to the point of where the intersection happened around moving from sales into it, because about, I would say what 20 odd years ago, they Imperial wanted to basically automate the Field Sales Force. So they wanted to provide the sales reps with a small tablet, to be able to sell and to record data. So this was like cutting edge them. And at that time, Siebel was pretty big before Salesforce is, you know, came on on the horizon. So, I was brought in as a basically a sort of product owner from the business to work alongside the employ systems integrator that we bought in sight, I worked with them to design a system global system, in terms of how to automate the sales process for the sales reps that I was managing. So the pilot was for the UK. And so I sort of got involved. And essentially, I never got back out on the road selling because from that day onwards, I was just hooked into in that role of product owner and you know, being the intersection between the business and the IT team to design and make sure that the requirements that we wanted out in the Salesforce were actually met by the application. So that role went on for many years, probably about 14 years, I carried that role through from system design to implementation to running it as a business as usual application and then enhancing that application over the number of years with new requirements. And new versions of Siebel so that’s really the turning point of my career where I moved away from if you like hard sales to sort of, you know, working in it but very much a bridge between business and it and then sort of that roll, you know, moved on and we then implemented Salesforce in, I think it was 2000 somewhere around that time. So we moved away from Siebel because we had customized it to death. Siebel was losing market share at that time. Salesforce was starting to make traction, lots of global companies were starting to replace Siebel and with Salesforce and that’s how I ended up again working with a systems integrator to redesign everything again. And review all the sales processes. So it wasn’t just a simple sort of upgrade. But we also took the opportunity to actually go through probably about seven or eight months of workshops to review every single sales process as well.
Pei Mun Lim
Can I just ask one question? Because it’s really interesting, what made what precipitated the decision to actually change. Because if you say that you’ve customized Siebel to death, that tells me that has a huge amount of sunk costs in it, there must have come, you know, either a specific pain or a series of pain that’s tips you over to say, right, we got to look at re overhauling the whole CRM, what was it that made it so painful that you said, we’re just going to redo the whole thing? It’s going to cost a lot, but the benefits are going to outweigh the costs? What was it that created that push for change?
Mo
I think it was, it was two things. One was the the, I guess, the time and cost that was required to keep on changing the application to meet the needs of the business. And that needs the business were changing quite rapidly at the time, because lots of legislation was coming in around smoking, and advertising. And therefore we need to react to a lot of things very, very quickly. And with Siebel, if you wanted to change something significantly, the time it used to take to make those changes was considerable. And the cost was quite, you know, extortionate. And there came a point in time, we’ve said, Look, you know, do we want to continue investing in Siebel, and keep on upgrading? Or do we make the jump to a completely new platform and do two things, one is not about making a technical jump, because it’s going to be the total cost of running, that’s going to be much better, lower than where, where we would see more, but can we also take this opportunity to bring some innovation and some change to the way we work? So it, you know, we did two things at the same time, we wanted to review our processes, and then wrap those processes around a technology that would support those, and allow us to move things around and react to the business needs very, very quickly, in an agile way. And we felt at that time, Salesforce was the right thing to do. Because the fact that it was cloud based not on premise, it had it was a component based architecture, where you could literally sort of take things like opportunity sales contracts, and work with those components relatively quickly, with low code. So there were all these benefits that Salesforce were bringing to the to the table, which see well couldn’t bring. And it was a commercial decision at the time to say no, it’s costing us too much, it’s too painful to work with the platform we have, we’ve got to take bite the bullet to make the jump. So that’s that’s that’s where the decision came from.
Pei Mun Lim
So I assume that throughout the years, you’ve built a team of Siebel experts in in house and with the help of a partner guess to get the changes that you want done. When you moved over to Salesforce for to happen and your whole team rescale upskill? What were the people who weren’t happy with the change that moved out? How is the process of change internally for your team, as well as for the users because things are changing interface will be different. The processes that we used to have no longer are not now no longer in use? How did the company deal with a change firstly within the team, and then ask the end users?
Mo
It’s a great question. I mean, we were working with a very large system integrator integration partner. And we worked with them and spent a lot of time around this whole area around how do we change? How do we manage this change from Siebel to a completely new user interface, you know, that the end users are going to use but also the people within the organization that’s supporting you? How are they going to get upskilled? So in parallel to the project, we had quite a lot of money invested in the change management aspect of that project as well. So we started very early on identifying end users in different markets that were bought into the workshops, they had a very early view of what Salesforce looked like. And the global integrator that we were working with. We’re very good at producing mock ups producing wireframes. So we had some real tangible things that people could click and say, Okay, this is what I used to do here. In the New World. I’m doing it this way. So it does two things. One, it reassures people because you’ve then got ambassadors in the business that take that message out and they can just cascade that to people saying, look, change is about to come. But don’t Worry, we’ve seen it with, we work with it every day, we think it’s going to be a beneficial change. So bringing those people into those workshops, those real end users at the very early stage really helped that change process. And they did these guys then then stayed all the way through the project lifecycle, because they were instrumental in the design. Because the design was based on people that were actually going to be using the application on a day to day basis, not by it, not by managers that are managing the the KPIs, they’re not actually using the application. But you know, the design was based on people coming in, that were at their selling, you know, at the sharp end of the business, and telling us actually does that work or doesn’t work? from everything around the process to actually the UI that we’re, you know, we were planning to present to the users. So these guys had the input all the way through. And I think that really worked well. In terms of the technical teams, yes, they know, they had to make a change from Siebel, to Salesforce. And again, we started very early on in terms of the certification prep process, you know, getting them up skilled, by taking the basic certification, like admin and platform developer. And, again, very early on, they were brought in to start to work in the sandbox with the developers, yeah, to set up things like profiles to set up users. So bringing those guys in very early on to work alongside the integration team, the integrants, the system integration team, that really helped because by the time we were ready to go live, they were very confident about using the platform. Because there was somebody that sort of was holding the handle way through, and then that whole transition moving away that the system integrator moving away letting the business then run that and the local, it was a lot easier, because we thought about it a 12 months at the very early stages of the project. That’s Yeah, it is, it is. And I know, it was a huge investment. And this is where I think, you know, I often see projects fail, because companies, when you talk about investing in change, change managers, you know, change catalysts, they see that as an additional overhead or cost in the project, right. But, you know, that, to me is a fundamental piece that needs to be considered before you even start on the project, to have that change management, you know, roadmap fleshed out, because if you don’t invest in that, you don’t have that power workstream running, the chances are, your project will fail. It’s quite either you will fail. So I learned quite a lot there in terms of how important change management is, and bringing the right people into the project team. And getting them involved early with what we’re building, you know, is the key to successful implementation and adoption. So yeah, as a, you know, something I learned and I preach, almost, you know, all the time when when I talk to clients, and internally with project teams and say, changes is an element you have to consider. And, of course, you know, ultimately the client makes a decision at the end of the day, if they don’t want to invest, you know, we’ve talked about it, we’ve raised the risk, it’s something they need to be aware of, you know, if they haven’t, and they’ve, they’ve, you know, we’ve we’ve, we’ve raised doubt, and they’re, they’re saying, Yeah, you know, we can we’re willing to have, you know, invest and, you know, put that change workstream in great, you know, that’s that’s something that’s probably wouldn’t they wouldn’t have considered had we not spoken about it. So I’m quite an advocate of that, when it comes to project is making sure we have change management covered.
Pei Mun Lim
Absolutely, I think what you’ve just shared there is a textbook case of how to do it. foresight planning, in the management of the people aspect over technology, bringing them in winning them over identifying key champions, and then working through that, instead of saying, Hey, you know, here’s a new system. Either you love it, or you know, you don’t I have question which is around data. With so much planning, at what point did you start looking at the data because using years and years of working in a platform and moving to a new one, data must be a huge part. So before your Salesforce project actually kicked off? How much time did you spend looking at the data to be brought over?
Mo
Quite a lot of time. I mean, that was the detail and one was all the parts of each of the set of process workshops, because what we had to determine is actually we’ve been collecting this data for a number of years. One Do we need it? If we need it? How do we use it? So you know, we had those those discussions very early on in those planning workshops because You’ll be amazed at how often companies will just continue to collect data. But actually not question who’s actually using that data? And what value does he provide? So actually, we went through a whole process of, you know, going through and field level by field level understanding, why are we collecting that data? What benefit does he provided? Do we need it going forward. And going through that process really helped. Because we did end up with throwing away a lot of data that we weren’t going to migrate, because we just didn’t feel we needed in the new world, it just wasn’t relevant. Conversely, we actually came up with new data elements don’t think we needed, which weren’t being collected today, which the business needed, because they needed that insight to be able to plan for the future. So it’s a two way thing, it’s about seeing where you are today and getting rid of the data you don’t need. And also looking ahead at your business and understanding what data you’re going to need and making plans to make sure that data is in ready for collection, or at least the ability to collect that data is there. So we did that exercise during the workshops, and there’s always a data stream within within that workshop. However, even with that level of planning, I think one of the most difficult aspects of the project was data. And data migration, I think people underestimate the level of effort that’s required when you’re moving large volumes of data from a legacy system to a brand new application and how that data then translates through. So it’s not just a case of lift and shift a piece of data it’s about and actually that that phone number is stored in this format. In the new system, it’s in a different format. So how are you going to translate that? And how is that going to map across, you have a or b, again, you know, we were amazed amount, the amount of time and effort that was went into the the data migration aspect of that project. more so. Because, again, I came from the business side, and I didn’t appreciate how much time that will take, you know, just to do the migration. So something that again, you know, from experience, when I, when I look at projects, it’s it’s, it’s a screen that’s often sort of tucked away, nobody really wants to talk about data migration. And, you know, I always worry about it, it’s some something, you know, keeps you up at night thinking, we’ve got all this data, and we’ve got to move for this client, how we couldn’t do it. What are the tools? You know, do they need it? How is it gonna be transformed and extracted? What tools are we going to use to do that? So yeah, you know, one thing I did learn was old, though you did a great job of planning the data actually moving it technically is a different kettle of fish. And, you know, it’s it’s, again, a danger area for a project because it could ultimately be the be the thing, that actually means your project fails, because you’ve actually not thought about how you’re going to bring that data through, you then end up, you know, your data just doesn’t doesn’t transpose properly. So, again, from day one, when the end user logs into a nice, shiny application, and they see the data is not right. Straight away, you’ve lost them. Right. You’ve lost lost lost the entire audience, because they don’t have the confidence in your system. Right? Yeah. So yeah, again, I learned a lot around data, because it’s a subject that is often, you know, like I said, Put down the list. We’ll talk about that later. That’s the last thing in the project. Actually, it’s nice. The first thing project.
Pei Mun Lim
Yeah, I totally agree. And I think when you say data migration, correct me if I’m wrong, but a big part of it, the the messy part of it is actually the cleaning, and the D duping, which should the responsibility should say, actually, it must sit with the client, because that’s their data, they own it. They know what’s best to do with it. And in a lot of projects that I see, they they haven’t tweaked that it sits on their lap. Yeah. And it kind of shifted to the pilot say, you need to do most of it. But the challenge then is to the cleaning part and the make the decision making part, which should be with the client. So I totally appreciate it. I think we can talk about this for ages, but subject in its own right. Absolutely. Maybe we’ll have one just just on that alone. But I’ll let you continue. So you were at Imperial and now you’re moving to a GSI Yeah.
Mo
God that so after 21 years working for a tobacco company, it was time to to, I felt it was time to move and also sort of working with other GS eyes, you know, so I was on the other side of the table as a client, right? So instead of working with a number of different yesyes, as well, so it just, you know, through conversation appealed to me Actually, I’ve probably got as far as I can within an end user environment, from you know, the The role that I was doing so the only way I was going to really progress and widen my horizons, use my skills in a much, you know, across industry and, you know, with different clients was to move. And that’s where I sort of made the jump into working for global GSI. So that was my first year move into that probably now, what, nine years ago that I moved into into the world of consulting and gsis. And I worked for a number of the large players, you know, the top four or five, we’ve been together Capgemini, as well pay working together there. So work for the likes of Accenture as well, etc. So, yeah, so my, my world has revolved over the last nine years really, using that experience that I’ve built up, you know, from the day that I left college, using that management experience using that business, and project experienced, you know, helping other clients to achieve their goals. And I’ve been doing that for nine years with Salesforce. So how
Pei Mun Lim
did how did you feel moving from an end time to is quite different? Wrong.
Mo
It’s a very different role. Yeah, but I found that, I mean, having worked as an end client, and working in business, I think it gave me an edge, because I really understood that when a client is, is really passionate about having something, it’s not because they’re being difficult is because really, they, you know, they need that for their business to be successful. And, you know, understanding how you deal with with different stakeholders within a business, because each stakeholder really is is, is really looking at their aspect of the business, not the wider business. So if you talk to marketing, they’ve got this, you know, they’re they’re just focused on, this is what I need to get my marketing done. And this is wanting to get my marketing job done. If you talk to finance, they’ve got their own set of requirements, if you go and talk to sales, they’ve got their own set of requirements. So you’ve got to understand, you know, and appreciate that within a large global business, you know, different stakeholders have different requirements. And your job is how do you bring those together? Because sometimes there’s going to be conflict in terms of somebody asking for x, somebody wants, why, and how do you sort of reconcile that want to make sure that you’re giving them what they want, but also doing that efficiently on a platform like Salesforce, you know, sticking to the core concepts of, you know, out of the box design, rather than sort of, you know, customizing where you can avoid it. So all of those design considerations from, you know, different stakeholders from their businesses is, is quite important to appreciate, not just think on a project, while someone’s just being difficult, because they’re not being difficult. That’s, that’s probably a genuine requirement in order for them to achieve their, their objectives for that, that part of the business. And having worked in as an end user, as a, on the sort of client side, I really appreciated that, right. So and, and it also gave me an appreciation of actually going and asking really deep questions about what people want. Because I think you and I know PE having worked in this industry for a number of years, that when a customer gives you a requirement, unless you’re, you’re really cute, and you can really sort of deep dig down into requirement, you’re just listening to a superficial requirement. And you and I can take that away and interpret that how we want and develop can’t interpret one way you could interpret different way, tested and interpreted a different way. And in the end, what you end up with actually is delivering something that actually the client really want, or it’s not quite what they wanted. Now, that’s the skill, right? So, you know, as a client, you know, don’t always assume the client is going to be in a, really defining that requirement to the entry level, because they’re assuming a lot of things that you understand that because you have the industry knowledge, you work with multiple clients, but actually, unless you actually really probe and really ask what that requirement means you actually end up designing system that people don’t really want or they it’s not met the requirement. So again, coming back, coming back to the experience I had, you know, on the business side, what I’d learned is actually, never assume that the integrator the system integrator understands what you’re saying. So I always made a habit of documenting my requirements to a level that we both understood going through those in detail, etc. And, again, that’s helped me, you know, move it moving away from end user to consulting because, again, I, I tend to, you know, you’ll get a set of requirements in a spreadsheet with just two or three sentences per requirement, a user story. I mean, user stories are great, don’t get me wrong, but they don’t give you the context and the level of requirements, you really need to translate that user story to a developer. So again, you know, it’s taught me, yeah, you know, user stories of basis for a requirement. But you cannot design off a user story, you’ve got to really probe down, really understand what that requirement meets, and fill the gaps before you go off and give it to a developer. So, again, you know, with a lot of projects, that and clients that I’ve worked with in the past, you know, we start with a base requirement, but he actually then, you know, evolves and refines and you end up, you know, getting the right people together to really understand what what that customer wants or that client wants, with that set of requirements. And again, having the appreciation and having learned that from a business perspective, I can understand that that’s quite important for a project to be successful. And you and I have both seen pay where we’ve got requirements that you think, what does that mean? How am I going to be able to give this to a developer to develop? Because it just, it’s just too vague? doesn’t give you any context? So I think, yeah, there’s a lot of a lot of those sort of things that I’ve, I’ve, you know, really taken from the days that I worked at 20 odd years in the tobacco industry to so working now for gsis. And, and having the appreciation really, of what the client, what position the clients in and where we where the GSI is. And the other thing I will say is, the client doesn’t really always know the answer, either sometimes. Because you’re always meet, assuming they’ve given you the answer, they they’re very clear about the requirement, the chances are, if you really ask the question, they probably don’t know what the requirement is. They sort of know what they want. But, you know, if it’s something new, they probably have a vision or a picture in their head, but they really don’t know what the detail of that requirement is. And until you have that discussion with them, you’re not going to get really to a point where you’re trying to meet that requirement. 200%, because you’re making a lot of guesses along the way.
Pei Mun Lim
Absolutely. Absolutely. So let me flip the question around slightly. Now. Is there anything you miss from working with an end client? But obviously, we don’t get working as a consulting partner? Is that? Is there anything that you miss from that world?
Mo
I guess I missed the fact that, you know, I can I can offload a lot of the responsibility as a client to, to a GSI. Yeah, that’s what I’m paying the GSI for is is is to bring the innovation, the responsibility, give me a fully tested and working solution at the end, you know, giving the headache of data migration over to somebody else to some degree, right. So I guess I missed that, because I never used to appreciate that as a client. Yeah, it’s like, you snap your fingers, I want x and you expect the GSI to deliver that, right. But you don’t really appreciate the work that goes behind the scenes of the GSI. To get you what you want. And that’s where I guess, you know, I’ve learned a lot as well, on the other side of the table is really appreciating actually, when I just flick my fingers a client, I’m not in the client really doesn’t understand how much work is involved in delivering that behind the scenes from a GSI perspective. So I missed that the days of when I just used to be able to click and say, can I have x and wait for a few weeks and suddenly appears and I can test? nor really caring about you know, who’s who’s built it, you know, how many hours and blood, sweat and tears has gone into this? So yeah, I missed that. Because I’m now on the other side of having to actually deliver something to the client. So let’s see, get back.
Pei Mun Lim
How about testing? What are your thoughts around testing? Because so you were as an end client, with a large customer. And one of the things that I found is a lot of clients underestimate the testing part of things. So how did you manage testing in yours? It sounds like, since there was a lot of planning that went in testing is something that you probably thought about as well. So what made it really successful?
Mo
Yeah, testing was a core element of our sprints as well. So we actually built our sprints around having enough time to test those sprints, and what was delivered in those sprints, and a full end to end use at at the end as well. And again, it’s down to Imperial, recognizing that they needed to make the investment both from a resources point of view, so freeing up people from the business to come along and test. So you know how I talked about having those end users in those workshops. Those were our testers. So they were the ones that helped to create the user story, they should know what they’re testing for, and come up with a test scenarios. And at the end of each sprint, you know, we had a week or two of Alicia at and being able to sort of, you know, raise defects you know, if there were defects or refining those What was delivered? Because somebody had misunderstood the requirement? Maybe? So yeah, you know, we did put a lot of time and effort investment into it. Again, it’s a it’s a challenge with a lot of clients, because the value of testing, in my view in projects is seen as relatively low. Yeah. People don’t really attach much value to that. They expect the system integrator to take on that aspect of of the project saying, well, Surely it’s the gsis problem to test this application. And the client misses the point, because it’s not the gsis problem. It’s a joint problem. It’s the gsis problem to test and unit test, what they’ve built. But really, it’s the business’s problem to test the actual thing works as expected end to end. And one of the things that I did when we were running you 80s, from a business perspective was, yes, we had test scripts, we had people used to run through a cycle press X press Y press said, Do you get the result? Yes or no. And that’s all very prescriptive. But what we used to build into our UI at at the end of the UAT, is a couple of days where I just used to give the application what we built to end users, and put them in a room and get them lots of cakes and snacks. And I said, right, do whatever you want what you know, try and break this for me, I am not going to give you a script, I just want you to play around with the data, just wanting to start a call and a call, you know, create activities, blah, blah, blah. And I just want you to try and do whatever you will do when you’re when you’re out on the road, you know, try and break it for me. And you’ll be amazed, actually, we picked up a lot of the bugs in those two days than what we did through prescriptive testing. Yeah, just letting people loose with it. Because people will do some really weird things. When you give them an application, they’ll move from one screen to another will try to do something in a different process or a different way. And they’ll raise that as a defect. And actually that triggers another? Well, actually, we didn’t think of that. Because there might be other people that may actually think like him or her and, you know, interpret that process differently. So to me the value of testing as as two things one, yes, you know, you’ve got to have prescriptive testing, so you can audit and, you know, tick off. Yes, you know, that does work as we expected as per the user story as per the process. But I think there’s also an element of testing, which I think businesses need to recognize is just give the people the application for a couple of days, and let them loose with it, and see what they find. Because that to me is, is unstructured testing. But actually, that does raise a lot of issues that you’d never thought would come out through structured testing. Because no matter how good you are at planning, testing, you cannot conceivably think about every single scenario out there that an end user is going to go through.
Pei Mun Lim
So there are two things there. That was just like Mark did in my head. One is around methodology, which we’ll get to that’s like one of my favorite subjects. The other one is where just just to just to provide context, and probably nuance for anyone listening in when you say raise a defect, I like fact that you’re looking at it from a different, quite holistic point of view. Because I think one of the challenges that we that we get in our lives when we’re doing projects for clients is testing is such a can be a contentious period, because it becomes a blame game, this thing doesn’t work. It’s your fault, because you didn’t build it right. Or it’s not our fault, because you didn’t tell us what you really wanted. So testing period can be quite a wobbly, emotional roller coaster. But I like the fact that how you’ve approached it. So I just want to just clarify, when you say defect, what you mean, in the context of that roll that you had is this particular thing isn’t doing what we would like it to do. And perhaps what comes out is a change request, I guess, in our language would be a change of the original requirements, because we didn’t think about it, as opposed to this isn’t working because you built it wrong. Correct?
Mo
Yeah. Yeah. Okay, so, so precisely, and I think you’ve summed it up nicely there pay because I think there’s the element of where you know, you, you think about test scenarios, test scripts, whatever you call them. You know, they’re all the same, where you go through a prescriptive process of testing what you’ve built, and you get an end user to do the same from their perspective. And that will give you a baseline of yes, it does work against the original requirement. But who says like you say, the original requirement is right, until you give it to an end user, because they they might, they might go through a different process. So step, step three becomes step five. They’ve done something slightly different. And the chances are, you know, 50% of the people out there are going to do the same. And we haven’t catered for that scenario. Now that scenario didn’t come out in the workshops. Right? Because we had a limited representation of the business, you can’t have every single user in a workshop, right? You’re gonna have one or two. And those guys didn’t come up with that. That slight process change. But the fact is, now you’ve given it and sort of people are messing around with it. Yeah, it’s raised a defect. It’s not a true defect, because everything is in working as per the design. But it’s actually another scenario that we never thought of, that we need to actually consider. Because if we don’t consider, we’re going to get, you know, 5050 support calls on day one, because it’s not quite, it’s not working as it should be. Not through no fault of anybody. But just we haven’t considered that scenario. So those things did come up in unstructured testing I was talking about that’s a great forum, to bring people in to just let them do freeform testing. Because you’re never going to pick that sort of stuff up through through a structured UAT
Pei Mun Lim
all right? I like the approach that you took, because that’s, I think, what a lot of clients should look at implementation of projects, more like a team effort between the partner and the client, to look at what would be the best kind of solution for the project, and not a demarcated experience of speed. There’s so much more I want to get into more really is I was wondering if you’d be open to doing a part two with me. At some point, yes. Yeah, of course. Yeah. Okay. I think we’ve just just really, really scratched the surface. I really enjoyed listening to your journey, and especially around how you’ve used Salesforce, to transition to a new environment from an end customer and a lot of the lessons that come out of that, I would like to unpack that a little bit more. And we’ll do it in part two. So thank you so much for your time today. Well,
Mo
thank you pay. I look forward to another session with you. I really, really enjoyed it. Thank you. Thank
Pei Mun Lim
you.