Try for free our course here:  FREE COURSE TRIAL

Discuss with like-minded people :  FREE EVENT

Transcript

If, like me, you've had a long list of potential projects to review, triage and investigate, you may have come across entries that need to be clarified. For example, it could simply just read "Hospitality Management System". There are no clues as to the purpose, how urgent it is, the relative size of the project and whether it is funded or not.

In this scenario, you may ask yourself, "How much time should I spend on investigating this compared to the other 30 line entries that are equally vague". I've spoken in previous podcasts about the starting point in structuring your demand, but this time I want to focus more on the next level of detail required for each request. Many organisations I've worked in have a scoping document, request form or an ideas document that outlines the essential information to help fit these jigsaw pieces of the puzzle, and it's at this initial stage where the seeds for scope creep, overspending, and delivery failure start to creep in. This is because it's down to the type of questions posed in the template.

Imagine the scene. You set yourself a task of understanding what the "Hospitality Management System" means. So you meet with the business sponsor to understand more and have your scoping document to fill out. How do you conduct the meeting, and what questions do you need to ask to ensure we don't sow the seeds of failure later in the delivery process?

--------------

Hi, I'm Jon, and this is a series of short articles called "Tales from a Portfolio Manager". I help people in corporates plan technology across teams. You could be someone who has a portfolio - of clients, projects, services or a backlog of features, and you have to manage them across a wide variety of teams to achieve any number of goals. I have been doing these roles for over 20 years for many corporates, and I have a few tales to tell. The best thing I can do for you is to encapsulate that experience into my advisory, online training and coaching so that you can reflect on how you solve some pretty challenging issues that you come across and, as a result, be more successful in your role. If you like the content, stay tuned for more episodes and try our courses for free with a link in the article description.

---------------

I find that these scoping documents start with a project management mindset, looking "downstream" towards the end deliverable, where the impulse is to answer the question "How much?" we control time and resources. Someone else decides whether it is worth doing or not. Yet, we need to look "upstream" towards the source of demand in the first place. So in this example, we'll need to reverse engineer the phrase "Hospitality Management System". The term itself could cover many activities. So what does the business sponsor specifically have in mind? What is the pain point that, overall, they are trying to resolve?

In the meeting, we need to get the conversation as quickly as possible onto their objectives. This will be understanding their agenda and how they measure success. They may be prepared to share what they have outlined in their personal performance development plan or what their line manager holds them responsible for. The higher up the organisation you are, the higher level the objectives will be. For example, if it is a department head, they will have to manage a budget, and they may be asked to reduce costs. Other things could be compliance, revenue, and efficiency savings.

So in one of my examples, I spoke to the Head of Customer Services. They have been given the joint objective with the Head of Sales in a hotel chain to increase revenue, and they have decided the best opportunity is to do this through up-selling room bookings to existing clients. Think weekend getaways, that sort of thing. In this instance, they have a call centre alongside a brochure website. In the call centre, they manage customer queries, take bookings, resolve escalations and coordinate booking changes with the individual hotels.

Given that there is already a booking system that the company uses in the back office, how can that be exposed to the front office? As a technologist, this may well be a sufficient trigger to start your investigations, and you could come up with any number of possible solutions, such as an upgrade to the website integration with the existing booking system, a new booking system, or an existing cloud platform that integrates into booking.com, for example. It will cost money, and inevitably, you'll need to come up with some estimate to ensure a return on investment.

The management team at the Call Center has spotted the opportunity where call agent time could be saved by giving direct access to the customers to make the booking themselves on a redesigned website, rather than having to ring up the CallCenter to do the job for them. Of course, with that efficiency saving, the call centre staff could be trained to do outbound sales calls instead. Is there another way? What about the marketing department? Can they not upsell through an email campaign? Yes was the answer. However, the business sponsor had yet to speak to the marketing department.

So you can quickly see where the phrase "Hospitality Management System" comes from, yet we're also beginning to see the tangled nature of delivering increased revenue through upselling. I've learned that in this scenario,  depending on the business sponsor, I would want to press further on questions such as:

• how they would do the upsell, 

• what kind of packages would they will be selling, 

• what other marketing campaigns would they need to develop, 

• the type of training and sales agent required.

I know these are not technology questions, but quite often, these questions have yet to be asked, and someone has already determined that a "Hospitality Management System" is the answer. Many other additional solutions also need to be implemented to achieve the outcome of increasing revenue through upselling, and any missing solution could derail the result in the first place.

I have worked in IT Departments where the assumption is that the business sponsors need to be accountable for the business benefits, and the IT Department only needs to be accountable for the technology solution. This "you do your job, I'll do mine" approach means that achieving the business outcome is still very much at risk. We need to identify those risks and additional activities to mitigate them. 

Here are more questions: 

1. What additional resources are available in the CallCenter and sales department to investigate and deliver the project, 

2. Who will manage and be responsible for coordinating all the different work streams?

3. Can we work together to find a joint solution?" 

This is where the rubber typically hits the road, where people are only sometimes available or capable of doing this research. This fact alone very quickly helps determine the priority of the project compared to all of the other activities that are taking place. If the organisation sees this as a sufficient priority, whether it's a business analyst from the technology function or a manager from within the CallCenter team, allocating the time to the feasibility is warranted. 

Let's assume this project is highly prioritised and resources are available for feasibility. We need to draft subsequent milestones or objectives to ensure that we deliver the outcome. I'm talking about a hierarchy of objectives aligned with each other. Creating this hierarchy of objectives is a familiar process to those who already apply OKRs or Objectives and Key Results in their work. In the meeting, it could be agreed with the business sponsor that the second level of objectives to align the increased revenue through upselling objective would be:

1. Creates access for customers to book online

2. Transfer existing customers to book online

3. Upsell new bookings to existing customers

4. To support the last three objectives, create and deliver a plan for upselling in the sales, marketing, and technology department.

In addition, you could also agree with the business sponsor as an initial target, what metrics qualify for success in each of the examples objectives above, such as how much revenue through upselling, how many customers book online, and conversion rates for each outbound phone call made.

This hierarchy of objectives, in a nutshell, is how we define value. The concept of "value" troubles quite a few of the people I have mentored and coached. Questions such as "How do I know if I am delivering value" or "How do we measure value" seem to me to say there is only one metric we measure against that we can point to when people ask us. We are delivering value when we resolve the pain points of our customers. So long as they can clearly articulate their pain points and the objective they're trying to achieve, that is value defined.

I go one step further with OKRs since delivering value requires activity. Suppose teams are fully empowered to deliver the objective. In that case, they can decide how that objective is fulfilled with the available resources and tools that portend to agile development, such as software, developers, and platforms. But at the moment, we are earlier in the lifecycle. We still have to decide which platform, system, solution, architecture, vendor, or even what skills are required for upselling; then, we collectively need to make some decisions on the approach as part of the feasibility study and business case preparation. 

Measuring the right things means knowing the right questions to ask. Adopting a risk mindset allows us to do that. What do I mean by that? We can review the success of previous projects by reading the post-project review documentation, asking how things went last time or looking at the issue log. This information immediately gives you the type of risks you will encounter on a similar project in the future. So if a sizeable proportion of the issues were to do with integrating front and back office systems, a likely scenario in our Hospitality Booking System project, we need to investigate options to mitigate that risk as part of the feasibility. And that's the point - knowing the history of what could be the potential blockers stopping you from achieving the objective means you will know the right questions to ask, understand the options, and it makes it easy for you to measure the right things.

So to summarise, adding value means that you know you will be successful when:

• You understand the highest level business objective and how the project contributes to that.

• You've brainstormed with a cross-functional team the hierarchy of objectives down across all workstreams, similar to OKRs

• You've planned the next series of activities to answer the questions and options on how to achieve those objectives best.

• You've adopted a risk mindset by reviewing the success or failure of previous projects and their issue logs on what could stop you from achieving success.

So there you have it. I have outlined some key points to make sure you are delivering value. There is far more detail in the Value Management course I provide, together with introducing more tools such as customer journeys, continuous improvement and aligning objectives. If this has been useful, and you want more information, subscribe to a two-week free trial of our SDBP foundation course link below. Stay tuned for the next episode of Tales From a Portfolio Manager.