Tales From A Portfolio Manager

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 with 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 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 here https://bta.news/w74 and subscribe for our limited free course trial here https://bta.news/42e . Wishing you the best, Jon.

Article 9 - Achieving Alignment with Adam Lacey from Assembleyou. 06/30/2023

8. How To Enable Innovation | Stay Ahead Of Emerging Technologies 06/01/2023

Article 7: Trust Enables Strategic Partnerships 05/17/2023

Article 7: Trust Enables Strategic Partnerships ------------ Links mentioned in the Podcast: Free Course Trial: Organisation Partner Maturity Model: Shared Outcomes Blogpost: Changing Gears Blogpost: ------------ 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 . --------------- /episode/index/show/baxterthompson/id/26864475

Article 6: How Do You Know When You Are Successful? 04/26/2023

Article 6: How Do You Know When You Are Successful? Links mentioned in the Podcast: Free Course Trial: 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 . --------------- 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 , 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: What additional resources are available in the CallCenter and sales department to investigate and deliver the project, who will manage and be responsible for coordinating all the different work streams? 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: Creates access for customers to book online Transfer existing customers to book online Upsell new bookings to existing customers 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. /episode/index/show/baxterthompson/id/26665710

Article 5: Creating a Portfolio of Work 04/11/2023

Article 5: Creating a Portfolio of Work Links mentioned in the Podcast: Free Course Trial: Imagine the scene. Your boss organises an improvement workshop to brainstorm how members of the Customer Success Team can improve alignment between what we do as a central technology function for a portfolio of about 20 key customers and the overall company's goals. At the meeting, He explained that he has a list of over 200 feature requests, projects and new demands and ideas which need looking into - and that list keeps getting longer. Also, your colleagues say many customers complain that we are not providing the service they want. Finally, the business wants to change direction and keep up with the new industry trends. So where do you start? What would you put down as a list of ideas? Think about your current work situation and how you currently do things. What works well, and what would you like to try out? I have a few ideas, and I'd like to share those with you today. 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 our courses for free with a link in the article description or here So let me start by giving you some background of my experience. When I began managing a list of ideas, projects, and services, I first used Excel. Also, each item on the list always had criteria related to the dimensions that were easy to describe, such as the size of projects, cost resources, time and objective. Invariably, one of my tasks was to update the different stakeholders on the status of each of these items. And that's where the conversation could quickly derail. As soon as a request made its way onto the list, there was an explicit expectation that I would do something about it, and infinite resources backed me up on delivering it. We all know that is not the case, and I've already discussed ways with you in previous episodes to deal with these expectations. I started by thinking the best way to do this is to sort these projects into some common scope so that I could create a program of related work activities. Then questions would arise about who, what, and why. Next, there would be scheduling, dependencies and priority decisions, so the next step was to talk about governance quickly with some form of committee. But wait - what about all the new demand coming in? How would I prioritise that with the existing portfolio of work? To help, I have often worked with a solution architect to think about how the jigsaw pieces of the future technology footprint would sit together. Typically, I found that when the customer makes the request, it would take three months to turn it around with some idea of whether it can be fulfilled, when and how, even if it is a simple requirement. This work does not even consider the business strategy, which often seeks to reduce cost, simplify and make everything digital. It is a complex problem, and if you feel this reflects some degree of what's happening in your organisation, I can empathise deeply. If you change one cog in the planning gearbox and replace it with another, it may not fit, so you remove all the cogs to see how they could all fit together again. What I can do I can start to outline some steps and a broader framework to guide your thinking. If, like me, at the beginning of my career, you're thinking about organising programs from projects based on an Excel list, I would caution that there are better places to start. One of the prerequisites of the whole exercise is a clear business strategy. Anything written down that explains, even poorly, the customer's plan is a good step forward. A better step forward is to research technology trends, your department's plans, and how that could influence your customer's strategy. Further, finding out the level of risk that the business sponsors are prepared to take is a critical insight since business strategy can be easily formulated into options based on that risk appetite - Do they want to do slow incremental change? Is the customer facing an urgent and critical threat to which it must respond, and most importantly, is the customer prepared to accept the level of disruption and the risk of failure should they choose to radically change the direction of their business? Suppose the customer needs a plan. In that case, I have a questionnaire. The main point is that the questions focus on strategic direction, business activities, business plans, pain points and objectives, with nothing to do with technology at all, except for the expectations of services or requirements they have in mind already to calibrate their thinking and what level of maturity the business sponsor has in terms of whether they are thinking in terms of solutions or business outcomes. This document is itself a basic strategy template. However, it does not provide insight or alignment, which is the key to helping you construct your portfolio. Invariably, Customers who present requirements on the technology function want their way, which may contrast significantly with your company's broader business strategy implications. As your conversations develop with customers, they also need to be discussed openly with your organisation's leaders to check that the leaders acknowledge this and have an answer on how to respond to customers' requests. I have found that this discussion between customers and the company leadership doesn't necessarily take place, or it takes place in the absence of a technology person present to help identify the impact and risk, and quite often, the interpretation of the business strategy can very quickly devolve into conflicting technology requirements between the parties. To overcome this alignment issue, the second tool I use is a strategy on the page (SOAP), similar to Objectives and Key Results (OKR) but also lists the mission, vision and activities supporting the objectives. Generally, if I am sitting with a customer, it takes me 2 to 3 hours to fill one out through a process of enquiry about the context within which the customer operates. Before the meeting, I can prefill it with the information I have gathered from the questionnaire I mentioned earlier. The primary point I find with this document is that it's the start of a conversation where quite often in the research phase, I probably iterate the documents every couple of weeks when I start having conversations with corporate IT functions and suppliers to research as high-level feasibility of solutions or how various business requirements can be fulfilled. It's a living document and is the main one I use when I seek alignment between business sponsors and solution providers. The secret to success is to compare SOAPs with different customers and company functions since this is where you can visually spot misalignment or gaps. The other thing I have learnt with gaining alignment on strategy is that more than one plan is needed. You need to be able to provide options on how they can fulfil their strategy. You remember I spoke about risk earlier - Let's say you've come up with potential solutions that are High risk - these can be transformative, innovative, untested solutions, something bespoke and custom specific to the customer's needs. Conversely, the low-risk option can be an already tried and tested corporate service. Bringing this back to the original problem of resolving a long list of 200 requirements in Excel, you can search through the list and categorise projects by scale, risk and customer objective. Three or four similar projects or technology enablers may have different risk profiles but the same objective. Having a conversation around this empowers the customer to feel they are in control when they understand the costs, risk timescales, etc., at a high level, and they have sufficient information to make a decision. I need to underline the point about objectives - the alignment process is not just between the goals of your customer, company leadership and technology function but also of the activity, requirement, technology enabler or project to the objective. When you do this, you find those that are surplus, duplicated and different flavours of the same activity. Fundamentally you align the portfolio of work to objectives. The other tool worth mentioning in this article is HOW we use the roadmap. Since most solutions have been categorised by risk and scale, they can be aligned onto a basic multi-year horizon roadmap where the scheduling is by impact and priority. For me, the roadmap diagram needs to be accompanied by a narrative that explains the decisions made and the risks involved, obviously with caveats around delivery, et cetera. Again, like the SOAP, this document is updated frequently. The objective of the exercise is not to produce the document but to ensure the document has sufficient relevant information to facilitate the conversation. Here is a quick summary of what we can include in our brainstorming meeting. Fundamentally, we need a common approach to defining and iterating regularly business strategy, which can then be readily interpreted into technology enablers. The outcome of which will drive a very different list of projects, programs and your resulting portfolio. This requires: 1) Asking questions focusing on business objectives, plans and pain points. 2) Consolidating this information into a standard format that can be compared with different customers, leadership and technology teams. I use a SOAP template. Ensure this facilitates an ongoing conversation between the different parties rather than being an end. 3) Align your list of projects and requirements to objectives and filter duplicates or surplus. Attribute the level of risk to each line item. 4) Consolidate this information, update your SOAP and roadmap, and present options on how objectives are fulfilled according to the risk appetite and budget of the customer. So there you have it. I have outlined at a very high level the process I have used to create a portfolio of work. There is far more detail in the strategy management course I provide, together with introducing more tools such as capability mapping and innovation. 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. /episode/index/show/baxterthompson/id/26506704

Article 4: Empathy Helps Unlock Alternative Solutions 03/27/2023

Article 4: Empathy Helps Unlock Alternative Solutions Links mentioned in the Podcast: Free Course Trial: 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; "Thank you very much for the information?" I hope it all goes well. "Let me check with my colleagues in central IT to see if we have anything already in place?" "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 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. /episode/index/show/baxterthompson/id/26353950

Article 3: Changing Gears from a Reactive Partner to a Strategic Partner 03/14/2023

Article 3: Changing Gears from a Reactive Partner to a Strategic Partner Links mentioned in the article: Organisation Partner Maturity: The five Competencies: Free Course Trial: 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 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: The five Competencies: /episode/index/show/baxterthompson/id/26230605

Article 2 - A Surprise Request 02/27/2023

Article 1 - Shared Outcomes 01/24/2023

IT Business Partner - The inspiration, the sell and the implementation 03/28/2018

FInding The Right IT Business Partner 07/17/2017

Applying Start-up Principles to Corporate Innovation 05/08/2017

Using influence to get business case approval 04/18/2017

Tales From A Portfolio Manager

TOPICS