Planning agile initiatives
SUMMARY
In this podcast, we talk about our experience with planning agile initiatives. How to do just enough planning just in time. We discuss the team you need, user stories, UX concepts and technical architecture, how to develop a release plan and estimate time and cost in a 2 to 4-week timebox. We also talk about the common traps, pitfalls and bad patterns we see in planning agile initiatives.
Shane Gibson
Welcome to the no-nonsense agile podcast. I'm Shane Gibson.
Murray Robinson
And I'm Murray Robinson.
Shane Gibson
Hey, Murray, good to see you again; it’s our second one of these. And today, we've decided that we're going to talk about initiation. Initiation is the work we do early, the work we do upfront, the chunk of work that, if we get it done, makes life easier in the future. But we don't want to spend six months on a Sprint Zero or a year on waterfall planning. We don’t want to wait for everything to be perfect before building some stuff with value and learning from that experience.
Murray Robinson
I've written an article about initiative roadmaps on Medium. Research shows that organisations in the software industry spend half their time and a third of their budget planning and design work before starting coding. So let's say you are doing nine months of development. Other people will have spent the same amount of time and a lot of the budget working out the requirements and design before you started. For example, I know of a big consulting company that just spent six months with a team of people doing initiation for a digital project. It's a long time and a lot of money. Much of this upfront effort is a waste because the requirements and the solution change when you get into coding.
Shane Gibson
I call it the big guess upfront. So, whether we're doing requirements, cost estimation, or building out a perfect roadmap upfront, we have a mountain of uncertainty. So, let’s guess, but let's make the time we spend on the guess equal the value we get out of that guess. One of the agile anti-patterns I've seen, though, is behaving ad hoc. That's the idea that we do no planning. We walk in, and a team starts magically building and delivering stuff with no work done upfront. And for me, that's as bad as those big guess upfront initiation processes. So, there needs to be a balance. So, did you say people spend half the time and a third of the budget on initiation?
Murray Robinson
That's normal.
Shane Gibson
What should it be? Does it depend on how long the piece of work is? For example, if we're thinking about something that we're guessing will take 12 months to deliver, should we timebox our planning phases initially? Then, based on that, is there a minimum viable number of weeks or months we should always do regardless of how long the work is?
Murray Robinson
Yes, we should timebox it. I can plan a six or 12-month project in two weeks, assuming that we have done enough customer discovery and market research to understand the problem. But sometimes you haven't done that. All you know is that you're not getting enough leads. In that case, you need to spend a couple of weeks testing concepts with customers to find the right problem to solve. But two to four weeks is enough to plan out your initiative, develop your business case, work out your high-level user experience design and your customer journey, architecture and roadmap.
Shane Gibson
So I'm just about to go off on a sidetrack around the business case. But I think we'll put that one on the backlog, and we'll spend one of the sessions having a chat about business cases. So let’s go back to what the initiation should cover. You talked about customer acquisition as a problem you want to solve. In the data world, we're often talking about a bunch of data we have that we think could help us make better decisions based on profitability, or lifetime value, those kinds of things. And so, we often get pushed to define the scope because we should have some idea of what we will and won't deliver. But we don't want to develop a 100 page Product Initiation document. So I tend to use a visioning statement that came out of Geoffrey Moore as a way of really quickly getting a one-page sentence that gives us an idea of what's in and out of scope, and we can do relatively quickly. What do you do? How do you get an understanding of scope in two to four weeks at a level that makes sense without overbaking?
Murray Robinson
So I use a combination of design thinking and agile. I'm going to assume that we know the problem customer or business problem that we need to solve.
Shane Gibson
One of the challenges I find is we often think we do, but when we articulate it, somebody else has a different view of that problem.
Murray Robinson
In that case, I would do initiation in two steps. The first step is to find the right problem to solve, and the second step is working out how to solve it. If you don't know the right problem to solve, then you should get a group of people together to define the objectives and the outcomes you want to see. Then do some customer and market research to explore it. If we don't know what the problem is, it could be almost anything. So we need to start talking to customers and subject matter experts straightaway. You should develop lots of ideas and prioritise them to work out which ones are best to pursue. I would create some user experience design concepts, mock up some advertising, and design a customer journey. Within a few days, I would put that in front of customers in face-to-face interviews. I would ask them about their problem, what they are doing to solve it now, and what could be done better. Then we’d talk through some ideas we had to see what they think. I would do that with a UX designer, a Product Manager and a Consultant. The idea is to have real customers coming in every Thursday to provide feedback. I'd go through three or four possible product concepts with customers and users in two weeks to see which one got the best feedback.
Shane Gibson
And so you, you treat that as initiation.
Murray Robinson
The first part of initiation is discovering the right problem to solve. Usually, when I get engaged, people are clear about the problem to solve, and they want to work out the scope, the approach and the time and budget required.
Shane Gibson
So initiation could include understanding the outcome we want to achieve and the problem to solve. So we have a shared definition of what good looks like if we deliver this thing. Sometimes, initiation may involve some early prototyping and research spikes to understand what's possible, and we put those in front of some customers to understand what has value. After that, we have a better idea of what we should build and who we're building it for. So we're doing that early to make sure we're building the right things.
Murray Robinson
Yes, that's to understand the business problem, the product, and the customer.
Shane Gibson
The other one is the platform technology. If we go into a greenfield site, and there's nothing in place, we need a bit of Agile architecture. We need to understand the moving parts and the features of a data platform. We need to know what’s there on day one and what we will build as we are going. From an app dev point of view, I want to know what framework we will use and our microservices architecture. We need to make some early guesses so that we can start that work. All those things can be done as part of an initiation phase. You just have to be clear about which ones you're going to do early on and which ones you're going to do as the teams develop value.
Murray Robinson
It's done by timeboxing everything. A perfect solution will take an infinite amount of time, but a good solution can be done, in a couple of hours, with people who know what they're doing. You need to plan on the basis that you're just coming up with something good enough to get you in the right direction, in the right ballpark with the right amount of money and the right sort of team. And then you're going to replan that as you go. On day one, I would define the business challenge and how are we going to work together. Then, we would discuss the business objectives and the results we expect. Then we could define the customers and their journey and explore the product features and what the service could look like. On day two, I want the team to be exploring the current technical environment and coming up with the first version of the solution architecture models.
Shane Gibson
And this is based on a team of experts— a group of people that have done similar things before. So they're not going into an area where they have no expertise. Because if that's the case, that's unlikely to be done on the day.
Murray Robinson
I don't think they have to be international experts, but they need to be experienced people. Senior people at the level of a solution architect, for example. You also need a senior user experience designer, senior agile consultant, a business domain expert, a product manager, and a technical domain expert. About half of the team will probably be in the company because they have to understand the business, the current technical domain, and the customer. And then usually, I find that some people need to come from outside. They need somebody to facilitate and organise the whole thing because people typically haven't done a quick initiation before. And often, a solution architect and a user experience designer. So I'm talking about a cross-functional team that works together. It's pretty intense work; you’re going to need to work full time for two weeks to get this done.
Shane Gibson
I agree with you on the cross-functional team. I talk about T shaped skills. So making sure the team has a breadth of skills to do all the work themselves, rather than handing something off to another group. So each team member needs the ability to deep dive when they have to on the bits they're good at, but they also need to have skills in other areas, so they are cross-functional. Nirvana, for me, is working with a customer who has a group of permanent people who are dedicated to doing this work for a long time. So if we're building data products, they will build data products for the next couple of years. But often, we deal with organisations that are project or initiative oriented. They don't have a team of people sitting there who will do this work and learn how to do it. Instead, they have this theory that they're going to start the job, it’s going to take some time, and then they'll stop the work; and hand it over to a BAU team. When we see that behaviour, we get asked the question, how long and how much? We say we need to do two to four weeks worth of discovery, and then we'll give you a guess of how long it is. How do you approach it?
Murray Robinson
So I approach it with a fixed price for a fixed team to do the discovery work in a specified time. The outcome of that discovery includes an estimate, an architecture, user experience design, a product concept, a whole lot of feedback from customers and a whole lot of testing of a technical POC. And we bring it all together at the end with a plan. During that process, I take stakeholders on a journey to understand what it means to do an agile project. I explain that the detailed scope varies within the time, budget and people available. We’re going to develop a plan to know what direction we're going in, but that plan will change every two weeks based on what we learn.
Shane Gibson
I hate the word plan as much as I hate the word project. But if I replace the word plan with a roadmap, then I get there.
Murray Robinson
It’s the same thing, Shane.
Shane Gibson
Well, no, because when we use the word “Plan”, we get a lot of behaviour. We've been taught over many years what a plan is; it’s a Gantt chart, it's something that doesn't change. When I use the word roadmap, people seem to be more open to the fact that it's a guess, and we can reprioritise. And it's okay because we're just changing when things happen on the roadmap. I know it's semantics but changing the term to a different language makes it more accessible.
Let’s go back to the discovery phase. We've both seen it when large consulting firms use that the discovery phase as a weapon. They start everything with three to six months of discovery by 12 to 15 novice consultants. They do the discovery using techniques they've never used before and create a raft of documentation that looks like requirements. And it doesn't provide a lot of value. So what's your experience on that, because I like this idea of time boxing. Discovery of two to four weeks means you have to be pretty clinical about who you're going to engage with and what artefacts you're going to create because you just don't have time to make too much.
Murray Robinson
Yes, timeboxing is critical. But what's also essential for me is getting honest feedback multiple times during that two weeks. Genuine feedback from customers and real technical feedback by developing a technical POC and implementing its elements. So, for example, if a client or company said they needed a new eCommerce platform, I want to see the technical people implementing stuff and connecting to actual data by day 3. By the end of the first week, they should tell us if the people we need to work with are available and if the data we need to get is accessible. They should know what interface modules on the cloud we need to integrate with our Microsoft Dynamics database. And they should be able to tell us if the platform we are planning to use is a good fit.
I was working on a project with a client who had engaged a large web design and development consultancy where I kept saying all this. But it wasn't until quite far into the project that we could get any technical people in that supplier to do any technical POC, where they were getting onto actual data and using it. And when they did, they had these major shocks and discoveries and roadblocks. So I want to find that out in the first two weeks. Not much later on.
Shane Gibson
I suppose it depends on what technology you're using. So I remember whenever we wanted to add some more compute to our data centres, it took six to eight weeks for rack servers to be shipped from Singapore to New Zealand if they managed to manufacture them on time and ship them. So we've moved to these cloud things. But I don't think we're there yet. I believe there are cloud solutions currently available and mature and out of the box. Solutions where you go to a screen, click a button, and you can start using it. But I think in the data space, we still have several components that take too long to turn on for an architect to try out. So, again, I think when you're doing your initiation piece, you want to identify the ones that are just there and easy and the ones that you're going to burn some time on. So I think it's the same thing you're saying. Do that proof of capability.
Murray Robinson
Yes. I think you should try and get a narrow, thin proof of concept that goes all the way through like a steel thread.
Not that long ago, I saw a consultancy spend enormous time and money writing very detailed user stories during initiation. Every time someone at the client mentioned a need, someone would write a story for it. They ended up with many duplicate user stories, with up to 100 stories for the same thing. The client had a big picture developed by another consultancy. But the consultancy doing the user stories didn't connect them to the big picture. So it was very confusing for everybody and caused a lot of problems.
Shane Gibson
I think we see that in Documentation. One of the anti-patterns I see is when people claim that there is no documentation in agile. That’s just crazy. If we're building stuff, we need to document it. We need to write it in the right way at the right time. We need to create a document that has value because it's going to take effort. So if somebody reads the document, what are we expecting them to do as a result? And by doing that, we can understand the value that document has and therefore decide whether we need to create it right now or not. So if I take that back to the initiation piece of work, why don't we do the same thing? We should say we're going to produce this document because this document will be used for this action during the delivery piece. And so, therefore, let's do it, but let's make sure it's fit for purpose.
User stories have value. They are a great pattern because they are well known. Documenting some high-level user stories that map back to the strategy or roadmap or architectural blueprint has value because it helps us understand what will be done. We can get some t-shirt sizing on each one to give us a timeline of how long this thing might take if all things go well. But if we're down to 200 low-level user stories and they’re rolling up to features and epics during initiation then, we're probably overbaking it. If we've time-boxed it, that means somebody has bought out the user story catalogue and ticked the box to generate the user stories for you without engaging with anybody. Or we're spending three months with 12 people creating those user stories.
Murray Robinson
I don't create detailed user stories during initiative planning. Instead, I get people to identify the product features that we're going to build and any technical components that we need to develop to support those product features. And then, we estimate their size and their value. So we end up with a prioritised product backlog at a feature or a technical component level, much higher than a user story. And maybe we'll have 100 features in there. I have a way of doing estimation very quickly; I can take a team and estimate 100 items in an hour quite easily using a process called affinity mapping or silent estimation. Have you heard of that, Shane?
Shane Gibson
It sounds familiar. And I've probably done something along the lines, but I'm probably going to need to read the actual definition to see if I did a variation of it or something that sounded like it.
Murray Robinson
What stakeholders want out of an initiation is to know how long it will take to achieve their objective, how much it is going to cost and how many people have to be involved. So you have to answer that question. You can do that by focusing on the objective and not the detail of the solution or the requirements.
Affinity mapping works like this. You get the team to brainstorm the product features and components and write them on cards. Then you write the Fibonacci numbers 1,2,3,5,8,13, 40 and 100 on cards and put them on a table. Then, you ask the group to identify the most straightforward thing to build, and we give that a score of one. Then we ask them to identify the most challenging item to create, and we give that a score of 100. It usually doesn't take long to agree because we're not trying to get dollars or hours; we’re just trying to say what's the smallest and what's the biggest. Then I hand out the feature cards and ask people to silently put them down on this ruler, from one to 100, wherever they think they should go without talking to other people. Once they’re done, I ask them to pick up anything they think is wrong and move it to where they think it should go. Then other people can move it again and so on. When things bounce around, we'll take them out and define our assumptions in more detail. Once we've agreed, we'll put them back in. For example, product search is easy if we assume it’s out of the box, medium if we need to set up many data categories and huge if we think it is a unique three-level search. So we reach a quick agreement on what it is, agree on its size and put it back in. Estimation is always based on assumptions, so let's just make some assumptions, write them down, and estimate. Then if the assumptions change, we've got an excellent reason to reestimate. All we're doing at this point is estimating the relative size of features and components. You can easily do that in an hour with 100 things using this approach.
Shane Gibson
So this assumes that the team have done this type of work before - so they have a shared language. We know we're building an e-commerce store, and everybody knows what product search is because they've all seen that before.
Murray Robinson
Yes. We have experienced technical people in the team, and we're doing this after a week and a half of research and investigation.
Shane Gibson
So they've already done some research work, some hands-on research work to get to this stage. So then, for the product search feature, is the only artefact we produce a sticky with the word product search or is there a bit more behind it?
Murray Robinson
All you're doing is writing down the assumptions you made as you go through this time box initiation. So you’re not trying to write detailed user requirements or user stories. You're just trying to write down what you thought it was when you were estimating based on the planning you've been doing. So just bullet points. And you put it somewhere so people can come back to it later. So when people have estimated the size and written it down, I ask them to do it again for business value.
Shane Gibson
So you're documenting the features in a way where there is some future value, there's an action you can take. When we looked at that feature called product search that we said was 13 points, we've got some bullet points that told us what our assumptions were to create it. That’s a simple piece of documentation that has value because there's an action which we could take with it later.
Coming back to business value. So again, you're just creating a series of buckets, from low value to high value, and then you're crowdsourcing a bunch of people to decide which bucket it feels right in, and that's enough. You're not going down to return on investment. You're not going down to the total cost of ownership; you’re not going to any absolute level of detail because it’s just not valuable yet.
Murray Robinson
Exactly. It's just not valuable yet. And it would take a lot of work to get down to that level. So, it's just not worth doing during initiative planning. If you're going to calculate ROI, you should do it on the whole product, not on features.
Shane Gibson
And the outcome that the product will have is not the features it's got.
Murray Robinson
Exactly. So we started at the beginning of this scenario by saying, What's the business problem? What's our goal? And what are the measurable outcomes we want to achieve? So new customers, sales, leads, customer engagements, cost reductions, whatever it is. So that's a goal. But it's also a way to justify what you're doing. And then what you're doing is working out how we can achieve that goal in a reasonable time.
Shane Gibson
So when you've got your value ruler, it’s given the goals and outcomes we want to achieve. This feature is less likely to get us to that goal than another feature or more likely to get us to that goal than another feature.
Murray Robinson
Yes. So we estimate business value points, and then we do release planning by working out the things that have the highest value for money first. So if I've got something that's 10 points of business value and two points of size, I want to do that early. But then a technical person on the team could say, “you can't do that until you put this other component in first”. From a product point of view, I don't understand the business value of that technical component, but I do see that we have to have it before we can get this thing I want. So we can go put in that technical thing first.
Shane Gibson
Okay, so you allow the team to override it with a sequencing where the sequencing makes sense from delivery efficiency.
Murray Robinson
Yes. Now we know the size and value of each feature, we can do a release roadmap. We order the features by value for money and check to see if this order make sense. Could we release it to customers and users this way? Then I ask the technical people to come in and put the technical components where they need to go so that the business features will work. However, technical people will often want to build a vast technical platform before any business value is delivered.
Shane Gibson
Give us six months, and we'll build the best shiny platform that does everything you want. I had one of these. I was working with an experienced team building a new data platform to replace a legacy one. They asked for six months to build the platform out, and I said we don't do that anymore because there's a chance you're going to guess wrong. They said we know exactly what we need. We built it for a month or two, and then we had to bring in our first source of data. They assumed that the first source of data would be a relational database, so they’d put in the technology that allowed us to connect to that database and suck that data in. Unfortunately, the organisation had just gone live with a contact centre application that was cloud-based, and that project had de-scoped all the operational reporting for that contact centre. So it goes live, and the call centre agents can take calls and type in notes, but they have absolutely no visibility of how many calls they've taken or how long the queue is. So the data team were told the highest priority was to bring that call centre data in. Unfortunately, that data was on a cloud application that they couldn't connect to because they hadn't built the API interface platform yet. So the idea that you can guess what the most important thing is and get it right every time is wrong. I'm a great fan of planning and some work upfront if that makes us more efficient in the future, but we have to timebox it. We often don't get those 6 to 12-month platform builds right.
Murray Robinson
The business priorities can change during that time. If you spent millions and six months building a platform, then everything could change around you. The business people could lose interest because you haven't delivered any value to them, so they pull your funding.
Shane Gibson
Or the technology changes. If you spent a month building a unique component, you could find three months later that a “software as a service” product turns up that does what you want without you making all that effort. So, we need to plan for a horizon that has value. Timebox it, but don't plan for the next three years because it's a waste of time and effort.
Murray Robinson
I ask the technical people to break the technology platform down into relatively independent components to deliver in a Sprint. And then plan to build the platform components that we need just in time to deliver business value. Then if things change, you haven't wasted all your time creating things you won’t use.
Shane Gibson
But that's hard. When I'm coaching a new team, I help them understand that you can take the elephant, break it down into smaller pieces and deliver them one at a time. Each piece has value on its own but, there's more value when they're together. The art of decomposing something complex down into smaller chunks is a hard thing to learn. I was talking to somebody working with a large financial institution building a data warehouse for eight years. He said they went agile a year ago, and he struggled to decompose the work down so it could be delivered in a duration of two to three weeks. But over time, they got better at it, and they are now providing small chunks into production in a two-week cycle. It was hard to learn, and it was hard to do. But they got there. And I think that's the key. It takes time and effort, but it's worth it.
Murray Robinson
I haven't found it hard to show people how to break up their work. I've only had a problem one time when a client solution architect refused to break something down so we could estimate it. It turned out that he had no idea how to decompose it. So we took it off the table and got some people to help him spend a week digging into it. When they came back, he was comfortable accepting what these technical advisors were telling him about breaking it down. If people have strong technical knowledge and a good idea of what they're doing, they can usually break a solution into its components relatively easily. For instance, you can break your platform into all its different functions and interfaces with other systems. Then you've got technical elements within the product package that can be turned on independently. So there are lots of ways to do it. The only way I would advise not to do it is not to break up a solution by layer. This idea that we do the front end, then the middle, and then the data is a disaster. Nobody should do that.
Shane Gibson
I agree. We have a habit in the data world of grabbing all data from all source systems and landing it first. Then we do the chunky work to interpret the data and make it fit for purpose, and only when we've done that do we start putting the visualisations on top. So we need to develop solutions in small chunks with a steel thread that goes all the way through from beginning to end. Because it's that final result in front of our customer that gives value, that provides us with feedback and helps us iterate.
Murray Robinson
Once we've done the investigation and planning, we need to work out how much it will cost. Our business people need to know that because they need to give us money and resources. So I ask the initiation team to work out how far they could get in the release plan in the first two weeks if we have a typical well-rounded team. For example, suppose we add four developers, a quality engineer and a UI designer, to the initiation team. Given that team, do we think that these first two weeks of work are achievable? I find that the team can tell you quickly if the plan is viable. And if it’s not, they will move some things into the second Sprint. Then I ask if that's reasonable, and if it’s not, they will move items into the third Sprint. Then, when they feel comfortable, we can use the first two Sprints to get the team’s velocity.
So now we know what order we want to build things in, and we know roughly how big everything is, so if we think we can do 50 points a Sprint, then we can work out how many Sprints it will take with the team we agreed. So in 6 months, this team of 10 people can get this far. Then we discuss this again as a team to see if we feel comfortable and confident with that plan. We talk through how we're going to do it and the assumptions we are making. In the end, we agree with the team about what's comfortable. Then we can estimate that we can get this far toward the goal in six months, with a group of 10 people. The product manager is there, and the stakeholders are there listening to all this. So we don't need to explain it again. We can say that's how far we think we can get in this time, more or less. But if you look at the business value points, we can see we are getting 80% of the business value in the first six months. So that'll be our plan. And then you just write it up as a good enough guess.
Shane Gibson
It’s good enough because any more work to estimate at a lower level of detail is just wasted effort. And there's a high chance that in the next six months, something's going to change. But with a roadmap, at least you can see when something new comes in, or there's a significant change, that we're now putting something else in there so the stuff at the end will drop off.
Murray Robinson
it's a forecast, not a commitment.
Shane Gibson
It's a guess.
Murray Robinson
You can say it’s a guestimate.
Shane Gibson
A guestimate, that's my favourite term. Because that’s what it is, it's okay. It's okay to guesstimate.
Murray Robinson
It's an estimate by a bunch of experts who should know what they're doing.
Shane Gibson
It's a good guestimate.
Murray Robinson
it's as good as any. You could spend six months on it, and you won’t get a better guesstimate than this.
Shane Gibson
And you lost six months. So, I think we probably covered a good chunk there. I like the process you use. I think we'll put a link in the podcast back to the medium article you've written. The takeaway for me is the idea that you should timebox your initiation piece of work. Doing some planning upfront has some value, but timeboxing makes you focus on the most valuable things. Depending on your context, you may create different artefacts as part of your initiation work, but that’s ok. The goal is within two to four weeks, we have a good guess, and we’ve done enough groundwork so that we can start running. And that has value. That's what I've taken away from this. What about you?
Murray Robinson
I want to talk about the other alternative, which you called the ad hoc Scrum approach. The idea is that we don’t do any planning because we're agile. It's like jazz. We're a jazz quartet. We're just improvising as we go. So what’s the problem with that?
Shane Gibson
There's no problem with that. It’s perfect. We don’t have to spend a whole month sitting in meetings.
Murray Robinson
You'll get what you want when it's done. So shut up.
Shane Gibson
Just let me code. I don’t want to do this airy-fairy sticky notes stuff. Just give me the coding window.
Murray Robinson
Scrum doesn't have a Sprint zero, but it does assume that somebody has done some planning. Scrum assumes that you start with a development team and a clear goal. You've got a product manager or a product owner and a good idea of what you're trying to try to do. Then in the first Sprint, you just start exploring doing technical spikes.
Shane Gibson
I've done that. And it’s brutal for the delivery team to walk into that room with absolutely no background work done and with a product owner sitting there telling them what they want. It is just brutal for the team to catch up, get up to speed, and start doing that work. So I think, a small amount of planning upfront is valuable. I don't like calling it Sprint zero because it has a lot of inferred behaviour that I think is bullshit. But I like the idea of an initiation or a roadmap or something that gets us ready.
Murray Robinson
The people who are paying us need to know whether they're going to get good value from investing in us. They need to know that they will spend X dollars on achieving an outcome in a reasonable timeframe. If you're a customer, that's what you want. If you buy a car, you want to know how much it’s going to cost and how long it will take to get it. You listen to a car dealer who said it would take what it takes, and it might get you to work, or it might not. It depends.
Shane Gibson
So I think there's a couple of lenses on this one. It's the difference between an internal team doing it for a while versus an organisation outsourcing the work to consultants. And it’s the difference between a custom solution and an off the shelf product. If I'm buying Software as a Service, I hate it when they ask me to contact them on the pricing page. There’s a mismatch there. If I’m buying software as a service, I expect to click a button, put my credit card in and start using it. Just like if I go to a car yard to buy a car, I'm expecting a car to be there, I'm buying a thing that's already known. If I have an internal team, that team is available to do the highest value work. So the executive’s job then is to prioritise the subsequent highest value work to fill the pipeline. It’s that middle ground where we're getting consultants or companies to come in and do the work under a project which is a problem. They're going to go and do the job, I'm going to give them a bunch of money, and then they're going to deliver this thing. I'm worried about whether I've got enough money to pay for it and if I'm going to get the things I want.
Murray Robinson
But even if I've just got an internal team, business people need to know whether the next piece of work is going to provide a reasonable return on investment. They have a lot of other things that they could be doing. For example, they could dissolve that team and put people on something else. So they need to work out what's going to give them the best return on investment out of all the options available. To do that, they need to know the relative business value and size of the work to decide amongst the different options available to them.
Shane Gibson
Let's discuss business prioritisation on another podcast. For example, if I want to build two products but I can only build one, which one should I choose. Should I do the one that’s quicker to build versus the other one, which has the same value? So let's put that one on a podcast, where we talk about how organisations prioritise work that needs to be done at a higher level outside of initiation.
Murray Robinson
I'm happy to do that another time.