Scope Triangle

Welcome to Fusion talk with Anouk and Steve. I'm sorry, you're wrong. I don't care. I know that understanding the requirements is important at the beginning, but actually understanding the features and the lifecycle and the backlog is more important if you think about it.

Yes, but not about users.

All right, so what you're saying is that before we can talk to the users, we need to help them understand about how we're going to move forward with the building of this application in a non technical way. You were about to argue with me then until I said a non technical way, weren't you?

Not before. We are talking to the users. We talk to the users to understand that.

Actually the users talk to us.

Yes.

They can say, hey, we'd like to be able to do X and Y on a laptop or a mobile device. Can you help us please? And we go, yes, of course we can. Do you have any money? All right, something like that.

Something like that.

All right, so look, we decided we're going to do another, another, another look at security, scalability and liability. And I kind of just brought up one of the subjects we were heavily discussing when we were putting some notes together. Again, but let's also make a few assumptions here before we move forward because we kind of want to get into this halfway through. And the assumption is that we have a scope.

So we assume we have a scope.

We're assuming that we have a scope so the user has some idea of what they want that we can put into writing. So let's assume that that's done. What we don't assume is that they understand how we need to build this and what we need from them. Yeah, so we assume they don't really understand app development, any of the processes or anything else. So we really need to help them understand. If we build it in an agile way, we need them to understand features and user stories.

Yeah, we need to get them understanding the business process that we are using to build this.

We don't use a business process, we use an IT process just to separate between the two.

The it. So why did the build process.

Build process is a key requirement for somebody in development. Do you know that handwriting is a key development for somebody like me?

For a doctor? Yes.

So we basically. For a doctor, you're calling me a doctor?

You have the same handwriting.

So yeah, you're not wrong. You're not wrong.

So we need to explain the building process to the users. If we are using agile, waterfall or whatever, method you would like to use but the user needs to understand that.

But most of the time we basically want them to explain to us in plain English language what it is that they need and then we need to help them translate that into what we require to be successful together. It's a partnership. Making this work is definitely a partnership.

Yes.

So what we want to look at in this podcast then really is to still take that security, scalability and liability, but literally start to talk to the end users in the business about those three subjects, help them understand what we need so that jointly we can be successful in creating something positive and with good value.

And by helping them understand that, we can try to find the impact of the app, what impact it's going to have on, the value in the audience and budget, time, numbers of users or anything like that.

Yeah, so this, this idea of app impact, which is a term that we came up with when we was chewing over this, the impact is on both sides. There's the impact poor decision making can affect the application and the business, poor selection of the right information, the impact on the build and the longevity and the issues with it. So this app impact is probably a nice way of saying, okay, let's look at the about what we're about to do, the money we're about to spend and make sure we get the best value from that investment to who and the why. The who and the why? Yeah. Who's going to use it? Why are we building it? Yep, there we go. App impact, the who and the why. Need a poster that you can buy in IKEA for that. If you're going to keep standing up and squinting at my post its because you can't read them. It's going to get going to start to get a phobia about it.

Yeah, but you wrote it sideways.

What you do is that what you're laying down for?

I'm not laying diamonds.

Because even though we use giant sized.

Post its, even then there is not enough room.

We're never short of ideas.

All right, let's go to security. I think that's safer. That's okay.

So what we have to remember is that most business people think, they think business processes or they think from a business perspective non it. So when we talk about security, it's from a slightly different angle. It hasn't changed much though. We still need from an IT perspective to understand who's using this and what their roles are. and also we need to think about content, but probably more so for from an end user perspective because they know the Audience. And they know the content.

Yeah, we assume they know everything about it. so, yes. And owners, a team owner or owner team for this app, is more important for the business.

Well, I think we touched on this in the last podcast a little bit in that we said, you know, who actually owns this? And we're going to talk a little bit further on when we come to risk assessment and liability, about where different C levels and stuff get involved with this and that dependency. But yes, there is going to be an ownership and that's really, really crucial because if we go back to simple things like rolling team sites out, if we don't have an owner of a team site, the team site will just either fail, then we're paying for it to be there, we're backing it up, we're doing whatever. But the, the focus from a business perspective is gone. Also, if we have questions about it, when it needs to be deleted, who's going to say, hey, it needs to be deleted? And same with an application.

Yes. Because the owner is also responsible for the content. He knows the location, where the content is going to be. if we can access that location, yes or no, or do we need to have something new, is it, can we reuse something or anything like that? So the owner is practically.

It's a key part of understanding where that's going to go. The other thing about the owner is that they will know the audience, they will know the who. So in terms of our app impact, who they're building this for. So when we ask those, the things that we need to know from it, you know, is it going to stay safely inside our own network? In which case the content that we've talked about means it can be protected under our existing DLP and all that kind of stuff. Rules. They don't need to know a dlp, of course. so we need to know whether it's internal or external, and how we're going to register those external members. we also then need to think from a liability perspective on those external members. What are they going to sign up to when they register for that application? There'll be certain legal things that they're responsible for. That classic AI tool that Microsoft issued about five years ago and a group of kids managed to turn it into a racist respond chatbot because they went in there and started, you know, persuading this thing that certain things need to be done. And so they didn't get to sign up. They just, you know, got to. There'll be certain liabilities, you Want to make sure your users do and don't do. And also those audiences need to have a scope and the benefit to using that application and the owners will know all of those things and that stuff. And that keys us into content. Of course.

Yes. That keys us into, the reusing of the content.

Yep, yep. So we got. Just took. I knew what you was about to do. You was about to go and move to three more bullets instead of focusing on one at a time and digging down on it. No, you weren't.

No.

Oh, okay. I apologise.

Go ahead. I can wait to explain.

So, you mentioned earlier about location. and I think that that is key to this from a security perspective. Yes, Steve. Okay, that's fine. Okay. It's going to be an interesting podcast. I pissed her off already now and so she's now not going to get involved.

It's one of those days.

That's okay. We listen, we can't complain. We're in Austria for goodness sake, trying to put together some shorts and, it's a busy time. It's a bit of time. Okay, so, location, I think you mentioned earlier, and it's important so the owner will know about that location and we'll talk a bit about lability and location and stuff in a little while. But of course, if we have external users, we need to make sure they can get to that external data. We, have internal users, we have different rules for them as well to get to that data. and of course we then need to know what's going to happen to that data. so is it just going to be collected or is it then going to take part in an important process? and therefore are those processes likely to do that? So from an IT perspective, user number one creates a piece of data, but then some generic account may need to process that data. So we need to understand the handover between the two. An end user doesn't need to know that, of course. What we need to know is what's going to happen to that data, where it's going to be used from a user perspective. You may talk now on the next one, if you wish.

I was going to talk about the reusability of data, you can reuse it. And that was also going to refer to the location it is.

I think that's important.

If you have your data on a specific location and you don't want external users to access it, but your external users need to access the app, then you need to make sure that you have a sync between those two, that everything keeps in sync but you can reuse the original data for it, then.

No, I agree. And when we was making these notes around this, there's a lot of interaction between security, scalability and liability. Liability and security especially. So if you're going to collect this data from a user and then you're going to report on it, for example, because that's reusing that data too. So for example, if it's an ordering system, so if we're ordering product, we're going to want to do reporting on who chose what product and when and where and how and we have a liability for So responsibility is probably a better word for it, but responsibility for managing that data correctly and respecting the fact that our customers have put their personal information in etc. Etc.

Yeah. And that's why compliance comes in as well.

Yes. Mr. Compliance Manager or data officer for your organisation is going to be a key.

Part of it manager or something like that.

From an end user perspective, I think it's often worth, for those early meetings, bringing the Data Officer into the scoping and the session so they understand the importance and if they have any questions about what the application and the data they know and now have a.

Contact person and also, that kind, that person will be very, big impact because he knows the compliance for at the moment, but he will probably be aware of what we need to go do in the future. That's a big difference. The rules are changing.

Correct.

so often. So he needs to be aware, we need to be aware of it and we need to be able to change things on it.

Yeah, it's true. I mean, you can tag a lot of this data as well nowadays, even in databases and things. So understanding from an IT perspective what that data is and where it's coming from and who owns that data. so for example, if I put in my company email address into your application, who owns that email address? I do, my company does, the domain owner owns it and they expect you to deal with it in a responsible way. And of course with NIST2 and all those new regulations, you're even more liable for doing things correctly. But in terms of compliance, in terms of data and reporting and our audience, there is a future direction for this, which is going to key into the scalability of the application.

Yeah. And if you talk about scalability, then we are talking about the business process, the business application lifecycle process.

Yes. So you wrote that down and I was going, wow, that's really cool. So what do you mean by that? How do you scope that? How do you explain that to the end user?

The business application lifecycle process is all about the owner expectations. So if you write down your initial requirements of, what the app is needing to do, your owner expectations is that at the end of the development of the app, you have the app, like what is requested and the business application life cycle keeps track on time and budget and everything like that.

Okay, but that's just the first build, of course. But it's bigger than that, isn't it?

It's bigger than that. So you have first build and then you start with the second and your life cycle keeps on coming back, every build you are doing.

Okay. And so we need to explain that to the business to an extent. And we're going to do that at the beginning. Of course, we talked about that in the intro. So we have this, this life cycle. So where we need an initial scope, our phase one release, for want of a better description. and then those expectations that will have a budget associated with it, but there's then also a budget that needs to think about the future. So we're going to need to understand the, from a user's perspective how this will scale. It might not scale up, it might scale down, but it will scale in some size or capacity.

Yeah. We should know from the business what they want in five years with. Yep. By example.

Okay. So we kind of need a strategic direction on their vision for the application. Not the specifics, but their vision. This application will start off by doing two sections of our corporate catalogue from an E sales perspective and years two and years three. We want to be able to bring in this catalogue and that catalogue. for example.

Yes.

So again, this is requirements early on. Requirements and defining what that application life cycle is going to be and what it needs to meet.

True.

Just so nobody is mistaken about what we're doing here.

True. It's a little bit the same like we have done for the translation project.

Yes, we have a number of things that we're working on together for different customers. But this, translation project was very simple to start off with. but we knew where we were going with it in terms of translating SharePoint pages. but I don't think it's about the strategy of that application per se, but it's certainly about the life, cycle of it. It scaled down to start off with because we had some technical problems. So our first release was less than it was going to be. But we also then know what the next Stage of release and the next one will be. Which brings us on to what I call a backlog in, IT terms. But of course, we had a great conversation about whether the end user knows what a backlog is.

Yes. So we had a little bit of discussion. We never have discussions, but we have discussion now.

I got indigestion. That's how bad it was. No, no, no, no. So we came up with some idea of a change log. So, I think it did bring us onto the point though, of helping the business understand what they're getting into.

Yes.

Because we understand apps and most of your developers, they talk foreign languages anyway than what the business understands. So you always need somebody in between the two. I guess that would be me, the business analyst. but you obviously need them to understand the stages their application is going to go through and whether we call it a backlog and explain that, whether we call them phases of the project, whether we call them features and user stories, we have to choose the tool that they need. And also, don't forget it's about training them on what to expect in future backlogs and future user stories and that kind of stuff.

True. And it's very important you talk about, talk, with your users to make sure that they understand the words you are using. If you are doing a change log or a backlog, they really need to understand what it's going to be.

So what we have here is that, they understand their strategy, they understand what it's trying to do, they have no idea how it's going to do it.

They don't need to know how.

They don't need to know how. No. But they do need to understand what we will need from them over a period of time. And they will need to understand why we expect them to understand now, why we expect them to know what this year will do, next year will do and the year after will do.

Yes.

So we do expect them to understand that.

And if they understand that and they are ready, they have done the business application life cycle, the change log and everything. We need to talk about risk assessments.

We do. You always need to talk risk assessment. I think we'd have already done a bit in security and we'll certainly do a little bit more in liability. But yes, we need to understand what the risk associated with this is and how important. And it looks like we're sitting in our room and the cleaners are working in the corridor, so hopefully you're not going to pick that up. It's all part of the fun so.

For risk assessment, the very first thing that came to mind for us was the limitations. What limitations we need to talk about and are needed or not that, the end users are knowing Those limitations are there?

Yes, and I think it needs to know them as well. So for an example, is it just local, you know, are you talking about local markets for this application you're building? If it's external, and do we need to limit it to those so that it doesn't grow too big? So in terms of scalability, the risk is that it grows way quicker than you can support. So, big picture, we release an app, the app goes viral, thousands and thousands of people start to order product, but you can only cope with 200 orders a day, in which case you've basically kicked yourself in the foot because nobody will ever want to order from you again. So you need to think about that. Yeah. So do we find some way of limiting the application to meet the strategy, and the number of things that the business can support? So, hey, we only release it to one country at a time, or we only release it to, you know, certain numbers of people to be logged in at any one time and then the rest just have to put into a holding queue. A bit like Ticketmaster. Ticketmaster had no ends of problems in the early days when you ordered tickets online and you had 60,000 people per concert and you had 10 concerts and all of a sudden you've got, you know, 600,000 people all trying to get tickets at the same time. And then the system couldn't hold it. And so what they had to do, what they did, of course, is you get put into a holding queue and then you just sit there for 10 minutes, listen to some nice pretty music with a number against it. So you're not holding up the application. You then when your number comes up, you get put through to the application.

So waiting queues on those apps are horrible if you really want to have some tickets for a concert.

Correct. They are. But I mean, it's an ideal opportunity to sell you things and advertise because you want the tickets. But anyway, so you need to understand what the risks are with too many people or also too little people. Yeah, it could well be. We say, we need to understand again, we need to help them, they need to help us. It could all be that, hey, if we only do it in that country, they're not very good with apps, and we end up with six people, in which case we should have done six countries, because that's what the appetite is. So we need to understand that risk and what we do to fix the risk.

Yes. And that's something it and business needs to talk about.

Yeah. And I think, the biggest one is how fast can it grow and then how do we do we put that in there? because, you know, if we build an application and we spend €100,000 on building that application and then nobody accesses it, then that's part of the liability. Which takes us on to that third section. The liability is, is it meeting expectations, is it over meeting expectations? All of which are things that somebody is going to have to deal with. Heads may roll. Some of these liability things are small, some of them are big. But hey, we've picked a few to talk about.

Yeah. Ah, the first one we were discussing was actually the owner owns the liability of the content, so.

Content liability. Sorry, what are you laughing at?

Ah, some people, some things never change.

Oh, because I keep interrupting you a little. I'm going to stop them.

Behave. Act normal.

You started this right at the beginning, you started this. That's okay. yes. Part of the problem is the way it's written down or the way we thought about it, because owner owns the liability of content. But it struck me we needed to explain the liability of content before we talked about who owns it. That's all I was trying to do.

Go ahead.

No, after you.

I forgot what I was going to say.

So you have an app, and you're collecting. We talked about it earlier. Who owns that email address that. That you collect? it's not. It that is managed, that is responsible for the liability, whether. Whether that liability is a compliance issue, which we can get onto a little bit later. The owners need to understand what their liability stands for. It's about the success of the product, blah, blah, blah. But it's actually, once that data is collected, they're going to report against it. They're going to manage it, we're going to store it and look after it. And we'll have a data officer that deal with the compliance of it. but the owner will have to decide what that data is going to be used for. and then the associated rules and regulations for it. Because we're not going to be there to tell them all these things.

No. And it's not a job of the owner alone. It's also with the compliance officer. He needs to talk about it. Because some of the things you just can't do because of GDPR or anything else. So maybe the owner doesn't know all the rules. But your compliance officer will know.

Yeah, and owners are terrible at this. I mean, we love our business owners, we obviously do, but if the owner's going, oh, we really should do a mail shot to all of our customers, and tell them about product X or product Y. They need to. That is, something they will need to discuss with the data officers. Hey, can I take these email addresses then? Can I reuse them in a mailing list? Well, yes, but only if the user is signed off for it.

Yes, and that's, Often when it's inside an organisation, it's not being asked.

No, of course. I mean, some things make sense for inside, some things make sense for outside, but from a liability perspective, you really only care about data that is not yours. There is some requirements for internal responsibility, of course, but I don't think that's necessarily around applications. Oh, that's an interesting question.

It is around applications as well.

No, but I think internally people have signed up for certain data to be stored because of their contract. Hey, you know, we get to process your name and address and phone number and date of birth and, and everything else. yeah, anyway, that's not for today. This is about the owner of an application and their liability. So I think early on at the security or early on at the early sessions, we said we need to put them in touch with the people that can help them make decisions and help them understand. and certainly content is one of them.

Yeah, and it's the liability of the content, but also the compliance of the content. So you need to make sure that everything is aligned with all of the compliance rules there are globally, country wise.

Or business wise, and different countries will have different rules.

True.

And so, yes, and so in terms of the owner's liability for this application, they will sign off on the compliancy, they will have to sign off on what the data is going to be used for and, that they've checked it with everything else. And it's silly things, isn't it? So, hey, we're going to collect all these email addresses and then we're going to do a mail shop because we've got the whole strategy around where we're going, then that's fine. So when the users sign up for the application, somewhere in the terms and conditions of signing up, you need to say, you know, we're going to email you or you need to. Nowadays, of course, they need to purposely add in.

Yeah, it's the same thing. I'm doing a charity event and they Register at the place where we are, at the tent where we are doing it. They registered there, so it's not upfront or anything else. And even there, we need to ask if we can use their email address.

What for?

To send out, the mailing for next year of the events. So we need to ask them. Even if they were there last year, we still need to ask them every single year.

Again, fully understand that. Then you get to the really cool stuff, you know, where you actually decide whether you want to check in the box or no check in the box.

Yeah, but it's on paper.

It doesn't matter. I get that, I get this. And it's online. It's fucking irrelevant. The point is, what I'm trying to get to here is that do you try to trick people into thinking they've signed for it? So by not checking this box, you accept that you will receive emails from us, or by checking the box, please send me these emails and news. So as an organisation, you have to decide which way you want to go. I just love it. You have to read them carefully nowadays.

Yes, but, to be over to answer that, it's just if you check the box, you get emails.

Yes, if you check the box, you get emails.

That's the safest thing.

But most people won't check the box. They think that they're checking the box to receive an email. But if you put the wording right, you check the box to stop being sent an email.

Well, I'm always surprised by how many people are checking the box that wants to receive our emails.

Well, that's because it's a fun event. They're going to. They want to miss it. But when you're sending marketing things out three times a week about the latest product, then that's a different requirement, isn't it? So, interestingly enough here, the end user is responsible for the wording of that, along with the ethical side of the company. Are we going to be open and transparent and clear about what they're signing up for, or are we just going to try and con them into accepting the first newsletter on the basis that they can cancel all the rest?

True.

So. And it is a part of liability, it's part of the ethics that, you know within the organisation. But it's probably a bit off key, but I just find it funny, the different wording of all these, checkboxes.

All right. another thing with liability for end users, they need to think about is dependency in business processes.

Yeah, I think so. So the liability is not Just about the legal, liabilities or the cost liabilities. it could well be that this is a key application in the key income stream of the organisation.

Yes.

Bless you.

Thank you.

You're right. Yeah. It was good timing. That was just about to answer a question and you sneezed into your elbow because she was trying to keep it quiet. I'll just tell everybody it's fine. If you'd like me to keep talking while you,

Yes, please.

I do. I keep talking then, while you find a way of blowing your nose or not sneezing. So, yes. So this application could well have a dependency within the organisation in a number of things and therefore the liability for making sure that it can stay available or stay part of that process is something else that somebody needs to take on board. And I think that really is a joint effort by the owner.

And it, owner ID and C level.

I think I put C level on there that, that identifies whether it's important or not. So if you look at this application, it's important if you're asking C levels to sign off for it or they're taking an active interest in it. So it needs to be available and they'll notice when it's not there. So it's all a bit upsetting. Or if it's part of the income stream. So if organisation is going to build an 30% of their business through an application, then that application now has a liability for meeting the company's bottom line or not.

Yes.

So if that fails, somebody's liable for that failure. So it's important to understand the dependency.

Yeah. And then the responsibility will be with the owner and it. If it's failing.

Potentially. Yeah, I mean, that's why I say it's a joint thing really. So the owner needs to shout at it when it doesn't work because they will ultimately, you know, be responsible for that. So. And that's cool.

And then, we add one more subject with liability.

Yeah, it's going to pay some money to build this thing. I mean, even if it's it building it internally, there's still money to pay for it.

Yeah, they still need to spend time on it, so. And also, budget responsibility is not only paying to build the app, but also if you have extra licences you need to have.

I think the whole end to end cost is true, it's very important. so licences is one. backing up the data is another. scalability needs to be built into that budget. If we have our strategy, we talked about strategies for years 1, 2 and 3 and understanding where that's coming from, then budget needs to be appropriate. and it, and the thing about that liability is that you have an income stream and you're now generating 30% of your income through your application and then you don't put enough money into making it available. So hey, 20% of those people can't access the app because it just opens up. Like we were online yesterday trying to book a ticket for something and all of a sudden, which couldn't, we were unable to, the screen kept locking and all that kind of stuff. So that's a booking lost, you know. And so if that is part of your income stream, there's a, responsibility here and a liability to making sure it's correctly.

And the tickets for going somewhere is fine. But I had the issue with my car, with parking my car and charge it, that's even worse because then other people are getting involved and impacted because they can't drive the car anymore.

That is true. And then you're going to start moving to Q Park instead of pparc, something like that, because they're not delivering the level of service. So that liability depending upon the dependency is actually quite important.

It is. So we talked about a lot of things here and security, scalability, liability. We see it coming back in all of the processes we are thinking about as an end user, but also as it. And I never thought about it putting them in words like this when app, development. But I think I will go and try to use it next time.

I think it's interesting, I mean we picked it up when we was at Google in terms of them talking about how they deal with their applications. You know, do no evil is the famous Google line of course. But ensuring that applications are suitable for what they need to be is important. So security, scalability and liability. It is true. It's not just a Google thing by the way. You can actually take these words and see them in quite a few areas. so they've just sort of taken that on board. But it was just something we thought you might be interested in, and how you apply it. And it's also business terms, they're not IT terms, where they're used in it, but they understand what security is, they understand scalability and they definitely understand liability even if they don't see it in the context of what they're doing.

True.

So I think that's pretty cool and I love the idea of doing it from a user perspective as well because we all have to do that. You can't go and talk it to the business and expect them to understand it. There's a certain amount of ego in there. Listen, everybody has to deal with it. Just freaking get used to it, you know, same argument could be then I need to understand how we market this company and how we make our budget decisions. And there is a certain amount of that in you get to a certain level in it. but no, we shouldn't be conceited enough to assume that they understand everything from an IT perspective. No.

And business doesn't need to understand it.

There you go again. This interrupting thing is a common. Is it? Are you catching the habit already?

Yes, I learned from the best.

Oh, nice, nice, nice. It's true though, isn't it? You suddenly get an idea as part of the conversation and you want to sit there and, and add to it. that's okay, go ahead. I won't complain ever again. But now you forgot what you were going to say.

No, I was going to say business, doesn't need to understand it, but it needs to understand business.

That's a very good point. I think you should make that an IKEA poster. No, that's interesting. Have you noticed that every other podcast we hear, they're all nicely talking to each other and they leave a nice big gap and they don't have these kinds of conversations that we have.

No, not, not many. Yeah, I, I know one that does the same thing.

Yeah, it's probably another one that I'm involved with. I get that. But. But I, I kind of find these real.

Yes. because we are also seeing this podcast like normal conversations we are having. Yeah, not really. one person. Yes. And by the fact that we are having those kind of normal conversation, it makes it always a fun podcast. And brings ID, gives you that UIDs, M me IDs. And we just bring them on the table.

There are four post its on the wall. That's all. That's what we do. And we make a few notes and work out where we want to go with them. and, and I do think it works. And yes, we will talk over each other and yes, we will get excited because we've got a new idea and.

Yes, we will make fun of it.

Dead right. So thank you very, very much.

You too.

I appreciate it. It is good fun and we hope you enjoyed it. It's an interesting take. I don't think we finished this yet. I've got a feeling we might just take security, scalability and liability and drill down a little bit more.

I think so as well. Steve.

Dolby signing out and saying goodbye. And have a great Easter weekend, guys.

Same from me. Sa.