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. so 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 have the opportunity to reflect on how you can solve some pretty challenging issues that you come across and be more successful in your role. If you like the content, stay tuned for more episodes and try for free our course here bit.ly/SDBPtrialb
Adam, from assembleyou, was kind enough to invite me onto their Power Skills Project podcast a couple of weeks ago. It would be very rare to find people who don't work in teams, across the departments and quite often when we have a conversation with somebody, we have an objective in mind, from deciding where to go to lunch all the way to negotiating resources for a project. However, do they get what they want? Do the people they are speaking to get what they want?
In this latest article, learn about the concept of alignment in relationship management and its importance in various business interactions. Discover how to establish alignment through effective communication, active listening, and understanding cultural nuances. Build bridges of trust and create clarity to achieve successful outcomes. Listen to get practical examples and understand the tips on what this means in practice.
Links mentioned in the article:
Other links mentioned in the article:
Imagine the scene. You're a technology director, and you're providing the monthly update to the executive board of your company. The usual finance, project updates, service updates and new initiatives are being discussed. After the regular interruptions and questions, five minutes before the next agenda item, you ask, "Any questions?"
In this latest blog post, I delve into a scenario that many of us have encountered in our technology roles - presenting a monthly update to the executive board and being caught off guard by unexpected questions about emerging technologies. I vividly describe the moment and the subsequent realization of the need to stay on the front foot when it comes to these evolving trends.
To help professionals like you overcome these situations, I provide eight key enablers that will empower you to excel in your technology role. From aligning team activities with strategic business outcomes to fostering a culture of innovation, I offer practical strategies that will help you navigate the ever-changing technology landscape with confidence.
Links mentioned in the Podcast:
Free Course Trial: https://bta.news/nmu
Organisation Partner Maturity Model: https://www.strategicdigitalbusinesspartner.com/strategic-partnerships#OPM
Shared Outcomes Blogpost: https://www.strategicdigitalbusinesspartner.com/blog/tales-from-a-portfolio-manager-2/post/shared-outcomes-8
Changing Gears Blogpost: https://www.strategicdigitalbusinesspartner.com/blog/tales-from-a-portfolio-manager-2/post/3-changing-gears-13
Avoiding the Friday afternoon bug: Imagine this scenario. It's 4 o'clock on a Friday, and you receive an urgent voicemail from one of your key account managers. They inform you that a customer can no longer receive order confirmations via the API with your systems. You know it's going to be a weekend of conference calls, troubleshooting, and persuading colleagues to find the root cause and implement a fix, all while hoping to have it resolved by Monday morning. Sound familiar? We've all been there.
In this post, I focus on a higher-level perspective rather than just quick fixes. I re-introduce the concept of the organization partner maturity model, where teams, departments, or organizations demonstrate symptoms related to their level of maturity as reactive partners. I discuss the ramifications of such incidents, which often form a narrative among non-technology peers and can impact budget decisions. I explore the trade-off between additional features and maintenance, often perpetuating a reactive mode that feels like a never-ending cycle.
To break free from this negative feedback loop, I emphasize the importance of trust. Trust measures the quality of our relationships, and it can work either for or against us. By demonstrating good behaviour, clearly communicating and delivering on commitments, negotiating shared outcomes, and actively listening without judgment, we can cultivate trust, build better relationships, and move up the organization's maturity scale toward becoming strategic partners.
-------------- 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 or here https://bta.news/nmu . ---------------
Links mentioned in the Podcast:
Free Course Trial: https://bta.news/nmu
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 or here https://bta.news/nmu . --------------- 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.
Links mentioned in the Podcast:
Free Course Trial: https://bta.news/nmu
Transcript:
Imagine the scene: you're having your monthly meeting with your business sponsor, going through the progress reports, project deliverables, service levels, and future ideas. They say, "Well, look, we have an idea where we want to improve the experience of our visitors, and we have found software which will help us achieve that. We're talking reception, booking meetings, desks and turnstiles. It's okay; it's "software is a service", so we can manage the whole process, start to finish, with the supplier directly. We've already had discussions with them, and they've given us access to a demo account. I wanted to let you know. So what do you do? Do you say; 1. "Thank you very much for the information?" I hope it all goes well. 2. "Let me check with my colleagues in central IT to see if we have anything already in place?" 3. "Help me understand the problem you're trying to solve in more detail?"
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. so 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 for free our course here https://bta.news/nmu Well, in terms of the questions, the answer I wouldn't give is the first one. I appreciate that the business sponsor has been transparent in letting me know, and I see that as an invitation to take a closer look. So I will go with the third response. Naturally, I'll be curious to understand what needs to be fixed in the visitor experience and what they want to see happening. In this particular scenario, I'm assuming that someone somewhere has done some quick desk-based research - a couple of phone calls and a meeting with a supplier and the solution has already been decided. This may be sufficient in simple scenarios; however, there are certainly far more factors to consider in corporate scenarios, especially the scale; we won't be talking about a couple of visitors, but maybe tens of thousands in a year. Another consideration is the do-nothing option. Is there a legacy system in place already? Is it out of support, or are there new requirements it does not fulfil? What would the staff do to facilitate visitor management if there were no digital enablement of the process? Would they use index cards, Post-it notes, Excel, spreadsheets and walkie-talkies to manage the flow? The downside risk of not fulfilling a requirement in the short term may cause reputational damage and require substantial additional resources to work the process with the incumbent error and embarrassment that ensues. So inevitably, there is a sense of urgency. Depending on the circumstances, sometimes implementing something local sooner does trump onboarding onto a corporate-wide solution later. Yet fulfilling that need with a just-in-time response may come with the expectation that a long-term alternative solution can be found and supported by corporate IT and placed on the roadmap. I've often found that the not invented here syndrome can quickly take root. So even after a couple of phone calls, people have already decided on the solution, and as a result, they are less open to discussing alternatives. Given the pressing need to solve many other issues, I understand why the desire to get stuff done and move forward doesn't go away. On the other hand, if there is a standard solution that exists within the company, people can get offended quite quickly, simply because it hasn't been considered, or since out of the 10th features that are required, only nine of them are fulfilled, and that one feature suddenly becomes the must-have feature dealbreaker. People tend to wrap their egos into whatever solution. THEY decide it is the best choice, and it becomes difficult to disambiguate between the ego and the solution. So if you offer an alternative, they can become offended. In this situation, I make it easy for them to adopt an alternative idea as if it were theirs in the first place. You can get caught up in a culture between "us" and "them", where the opposing team rallies around their idea of how the problem should be solved vs the other team and their idea. Suppose different teams in diverse parts of the organisation employ empathy to understand their counterparty's issues and way of working can help different teams. In that case, having a more rational conversation about the pros and cons of different approaches is easier. That may mean walking through the experience and, in this instance, pretending to be a visitor, receptionist, or employee looking to use the office for the day. I have tried to find time with people to help them understand an alternative perspective. Often, people are not in listening mode; they are in "just do it" mode. Your professional credibility is based on whether you can "just do it" rather than helping them understand the broader picture. Trying to break down culture into something more collaborative is more than a single-person task; it's a collective endeavour. So what do we do when we're faced with this issue? If this is the situation that you are facing, then leading by example is the best way forward. So, for example, rather than only representing the corporate technology function to the business sponsor and using that as the basis of your authority, an additional source of authority is instead drawing on the empathy you can generate regarding your understanding of the business problem. Suppose you have spent time understanding the issue, walking through the process identifying with your colleagues, and understanding the opportunity and the customer journey. In that case, they can see that you are on the same page as them, so when you offer an alternative opinion after some time and consistent behaviour, they may be open to a broader debate on how to solve the issue. So you're probably thinking right now that's all very well and good, but I can't afford the time to spend doing this walk with me empathising approach to solving business problems. I agree that the amount of time it takes can be substantial. I find that my diary gets full of meetings, back to back, hour after hour, and the time I set aside to do research or spend time with my colleagues has suddenly evaporated. These are hard choices, and it is a question of priority, but our investment will have a return. So imagine the scenario where you have exercised empathy and, as a result, established more trust; how many crisis management meetings and sudden changes in direction would you have avoided? Since we have been able to influence the decision process much earlier on in the lifecycle? Stay tuned for another episode of Tales from a Portfolio Manager in two weeks.
Links mentioned in the article: Organisation Partner Maturity: https://bta.news/aqb The five Competencies: https://bta.news/25n Free Course Trial: https://bta.news/nmu Transcript: Imagine the scene. Your boss has just come out of a meeting with the finance director of your company. It's September, and he looks at you and says, "time to sharpen your pencil; it's budget time again". Not only do you have your day job, but you now have to review pages and pages of excel spreadsheets and magically conjure estimates based on abstract ideas of what you think your customers want. And then only after building this immense forest of numbers for the finance director cut it back again. You're probably thinking to yourself, "what's the point? Even after it is approved, everybody wants to start everything in January, and we're often unable to complete the budget simply because we don't have the capacity to spend it!" Fortunately, you kept your thoughts to yourself, out of your boss's hearing. I have been exposed to many situations like this, so this is not uncommon. This yearly ritual of forecasting your project spend for the year can sometimes feel like a chore. So, whilst it could be worse - after all, there could be no planning, is there a better way? 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. so 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 for free our course here https://bta.news/nmu So let's imagine another scene: you're 18 months into the future, and things look very different. On the relationship front, you have a regular cycle of catchups with your customer/business sponsor to ensure continued alignment on where they are with their plans and current situation and whether there needs to be any adjustment. That's not been easy to get to - since you've had to slowly build the level of trust so that they share their plans and thoughts, and you've had to demonstrate responsiveness to what were some outstanding issues before you could even start talking about the future. On the value front, you've tried to understand your customers' needs, spend time with them, and know how they work and their daily issues. Even then, the level of the conversation at the beginning was like taking an order in a restaurant - and you had to work hard to steer the conversation more to solving the business problem rather than finding a technical solution. Similar to hanging a picture rather than buying a drill. You've considered what they are trying to achieve and what's stopping them. You have listed a series of measurable outcomes that crystallise these. On the Strategy front, you've organised these outcomes into a clear mandate that the client team can accept as their plan over the next three years and created several themes into which you can allocate business activity onto one sheet of paper (or slide). At this point, the magic starts to happen since you can relate back to the various central technology teams on how they can enable business initiatives. This activity has not been one conversation but a continuous discussion where you've had to work together to figure out what could be done in the short term, if any existing solutions can be leveraged, or do you need to procure or build new solutions to enable the business client to do their job. On the portfolio front, things are taking shape. There has been quite a bit of back and forth during the year, shaping the demand into something that is starting to look very much like a roadmap - and whilst there has been some jostling for some work to be done immediately, we're talking for the first time about projects that go beyond 12 months. There are some other tangible quick wins you've been able to do - a kanban board of ideas and requests that now gets prioritised. This board gets updated every two weeks with the client to report back on the feasibility of the project or feature request and where you have time allocated to look at agreed requests for the next two weeks. Finally, you've instigated a quarterly strategic portfolio review of the roadmap, where you check whether the situation requires any changes, agree on work packages for the next three months and sign off on those deliverables that were instructed a quarter ago. On the Organisational front, naturally, there has been a significant change in the approach to the way people work- one of the tricks you used to get people to open up was to demonstrate a pilot with one client and be successful at a small scale first. One of the quick wins clients saw was the different types of conversation and how it was documented. It helped them crystallise their thinking on their goals, and they could see how technology could help. Whilst inevitably, some people would "kick the tyres", every discussion point was to sell the benefits that were unique to them. Based on their response, you quickly see who would be the detractors and advocates for the continuous improvement initiative you started, so you knew whom to ask for a favour and whom you would need to keep a close eye on. Both business clients and the technology function are far happier with this approach since they now have clarity on what's coming downstream, there is sufficient information to scope projects and enable better decision-making - and in fact, you're a lot happier because you've, in effect moved away from a lot of late nights estimating a yearly budget to regularly updating a budget, a roadmap and a strategy every quarter, where the least defined and vague ideas, are those that are fortunately the furthest out, and not stuck at the top of an excel spreadsheet with the implicit expectation that a project team will do it on the first day of the new financial year. So with this success in the bag, now you're ready for a much bigger deployment across the rest of the organisation. What I have outlined is achievable, and the benefits are tangible. I have done these in different organisations in my career, typically moving from what I call a reactive partner to a strategic partner maturity. In this podcast, I've also alluded to the five competencies that make up the SDBP practitioner certificate, three of which are online and being taught now. Also click on the link below to view the Organisational partner maturity and a more detailed look at the five competencies. Stay tuned for another episode of Tales from a Portfolio Manager in two weeks time. Organisation Partner Maturity: https://bta.news/aqb The five Competencies: https://bta.news/25n
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. so 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 for free our course here bit.ly/SDBPtrialb
It's my pleasure this month to discuss with James how he has made IT Business Partnering a core theme of his IT department at the Dog's trust. I delve a little deeper into what makes James tick to elicit some key traits and behaviours that make IT Business Partnering a success. It helps other IT Business Partners understand "How do other people do IT BP?". Some great tips that resonate strongly with the 12 principles of IT, a blog post which triggered our conversation in the first place.
A corollary to this conversation is the Nature vs Nurture debate. I suggest James is naturally successful at what he does and I position myself as someone (process, technical and engineer) who has had to learn through various iterations and stepping out of the comfort zone to practice what good looks like in terms of communication, business perspective and strategic thinking. I find it reassuring that the practices we encourage on our Convergence Essentials® workshop are aligned to the behaviours that Jame's demonstrates. Thus, whether we are naturally gifted or not we can achieve the same business outcome. What do you think?
Today we discuss with Chris Hodgson some of the innovation principles employed in Start-up companies and how they can be applied to the corporate environment. Chris outlines the three horizon view to innovation, the very different approaches required for each, their measures and the different teams of people that make them work.
To understand more about this, google "Baxter Thompson Innovation"
or email at info@baxterthompson.com
Your host Jon Baxter is helped by Robina Chatham to understand the finer points of how to deal with executives in the boardroom and persuade them to agree on his business case. Great podcast for those people with a technical focus!