A surprise request knocks your plans off balance?
We've all had new requests drop on your plate that should have been ideally notified to you a few months ago How do you handle them? Here are some quick notes:
Hold your fire until you've done some research on the context, the problem and the potential solution
Look at alternatives that also may not require tech
Negotiate and prioritise the planning with the different teams on the delivery of the requirement
Sounds obvious? Listen, watch the media or read the transcript below to get practical examples and understand the tips on what this means in practice to square the circle.
You can listen or watch on your favourite platform:
Try for free our course here: FREE COURSE TRIAL
Transcript
So imagine the scene. One day, you receive an email from a software provider asking for details on the APIs that manage the data interaction between your customer's database and the outside world. Your first thought is that it is a phishing attempt, but before you click on the spam account, you notice the name of the Marketing Director in the email.
On second thoughts, you read the email a lot closer, and there is too much proprietary information in the email for it to be just a phishing attempt, so to check, you forward it to the marketing director and ask them whether they know anything about this - "yes" is the reply. They have already signed a multi-year deal where the supplier will enrich your B2C customer data so that they can target their marketing campaigns better.
This is news to you, especially since you've just met with several of the marketing team's senior management, updating them on the product plans for the next three years and reporting on the service metrics. They have had ample opportunity to disclose their plans. Surely they must be aware of our marketing functionality improvements to the platform?
So what do you do?
Complain about the fact that you were not informed, this was kept secret, and they didn't check with you first?
Tell them suppliers cannot have DB access unless they undergo a supplier audit and information security review
Try to understand why they wanted to keep it secret and see if your product roadmap included this specific marketing requirement
I'm jon, and this is part of 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 technology portfolio - of clients, projects, or 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 technology role. If you like the content, you can subscribe for a free two-week trial of our online courses at the side here ->. Thanks to those who have already subscribed; I look forward to speaking to you soon.
Before I give an opinion on which option would be best, let's take a step back to understand the bigger picture. I've encountered situations where perceived withholding of information is common. There are many possible reasons for this - it could be company culture and politics, and that can drive through different teams vying for decision-making rights or to increase their importance within the company.
It could be simple oversight where in a large company, information like this just falls through the cracks because of the number of people to engage in getting something done; people haven't applied sufficient thinking to join the dots. Other times, there is a history where expectations have been left unfulfilled, and the only way to get something done has been to do it yourself instead of relying on central functions either because there need to be more resources or budget or it would take too long.
Another step we need to take is to acknowledge that there may be some shared reasons between the different teams as to why there has been a communication breakdown. It's not just that the 'other' side is evil and out to get you. So those of you who are nursing some personal gripes need to put that idea to one side and call on your rational focus and solve the problem in hand. Be prepared that other teams need to be sufficiently diligent and, in fact, to give a well-planned and agreed outcome, this requires actions from all people involved in the future.
My approach to solving this issue is to research and engage with the relevant people. I would need to check the following:
Where is this requirement on the product roadmap? Given the company's strategic direction and the marketing department's needs, should it be there? Answering these could be challenging, but typically there is already some history around both aspects, and we need to join the dots.
By asking, "how can we achieve the same objective if delivery cannot be delayed?". Are there any existing substitutes or workarounds that do not require a technology fix - this, again, may require some research and preparation before having the conversation.
That conversation's outcome could drive a series of further discussions on the relative prioritisation and dependencies required. I've found that there is typically a short-term workaround - to get us over the hump of this initial requirement (if shown to be valid and urgent) and, if that means "plan A", some acceptance from the requester about the delay as we do the required due diligence.
Most technology teams want to help and work towards the business's outcomes but find the arbitration and negotiation of priorities messy. The prioritisation of this plan can depend on two other often overlooked things - the first is what personal commitments you make to your colleagues in this situation (to be agreed upon with your line manager). The second thing is what commitments the other teams need to make to find an agreed solution.
I've found that the work required to understand the solution is a cross-team exercise, and there is a risk one person ends up gap-filling, which can lead to bottlenecks and unforeseen delays. These expectations need to be called out early, and people need to understand their commitments to help reach a decision. As a final thought, I've also had to check in the past the legal status of the contract with the supplier since we need to assess the legal and cost impact should there be a requirement to change course.
Inevitably people have short memories, and depending on the organisation's culture, this situation ranges from an exception to the norm. You're not alone. Plans are not set in stone but need to be constantly updated. So telling the story of why the plan is in its current state and the changes made are as significant as the plan itself.
Organisations can improve their "maturity" in how they plan technology, but this typically is more than just a new policy document or process template - it requires the organisation to change regarding people's attitudes, performance and collaboration.
So stay tuned for another episode in the next couple of weeks of tales from a portfolio manager.
