Try for free our course here:  FREE COURSE TRIAL

Discuss with like-minded people :  FREE EVENT

Transcript

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.

----------

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 implicit 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.