Demand & Delivery
During the research phase of writing The Platform Owner’s Guidebook in late 2020, I sat down for a discussion with the CIO of Forrester Research, Mike Kasparian, who shared his experience of driving the technology strategy for his business. While we began chatting about governance, our discussion led us down many paths where we covered managing teams, outsourcing, and taking a holistic approach to platform projects.
When considering governance, I often begin with benefits realisation and work backwards from there. This gives us insight into what we are chasing and how we set ourselves up for success.
“Historically, we would think about only time and budget in terms of technology delivery,” Mike tells me.
Obviously, things have changed as the role of technology has become, in many instances, determinant of the success of the entire company. Mike shares that he also works backwards in order to effectively set goals and to ensure progress is measurable.
“Another major difference in the standards we set ourselves when engaging in technology delivery compared to when we started is that when we talk about realising the benefits, we once judged this by whether we launched a good product or if it was on time. Now, we also have to think about whether we handled things like change management well, and what the overall value and outcome for the company is.”
Mike reveals to me a bit of 'dirty laundry'. He observed governance framework failing at Forrester. At one time, there were projects beginning in departments all over his company, all drawing on the same set of resources. As a result, there was confusion, burnout and inefficiency.
“To overcome this, we put into place a function of oversight at the executive level, whereby all projects must get the OK from a company perspective… larger projects that involve a cross team effort, take a couple of months and draw on resources are put in front of the executive team.”
From then on, Mike tells me that the decision to go forth with a project became a standard business decision, that takes into account the value of it for the business and what resources are going to be needed to accomplish it.
Naturally, Mike and I began discussing what happens once these projects do indeed get the go ahead. I have seen two common models of delivery within organisations. The first method is what I refer to in the book as 'eating your own dog food'. The people who create and engineer the platforms are also the people responsible for maintaining it. The other emerging practice I have observed is the desire for companies to remove the burden of managing from the teams delivering new projects, and have a maintenance or support team. The major concern that any type of split between your employees working on maintenance of a platform while others get to work on the new, exciting projects is that people may be hesitant to join the clean-up crew.
“You need to keep people engaged, but you are right. People do want to work on the new and exciting things. Typically, our process is cycling folks into the maintenance team and then see them progress into the projects team as we continue to scale up. This works well in our case as we have an internship program where they begin in maintenance and are given exposure to the business, allowing them to grow their skills set. There is so much business acumen needed in these roles, and not just knowledge about an application.”
Maintenance is considered to be the less glamorous aspect of platform delivery. However, it is highly important
“I think now I have drilled home to our board that if we put these projects into place, we need to ensure they are functioning their best.”
I liken it to an athlete who has just won a race. Just because they are at their peak doesn’t mean they can stop training and sit on the couch. If you are standing still, you are actually going backwards.
Moving our discussion into the space of expanding teams, I was curious to know how Forrester utilised their vendor to bring on crews of people to assist with delivery.
“We have brought in outside people from the vendor and have often tried to pair them with someone internally, so there is still internal business knowledge while ramping up the horsepower.”
This, I imagine, would also bring a diversity of thinking to a team that could obtain great value from a different perspective.
“That’s particularly nice when there is a new bolt on, like a CPQ application. Pairing our team with people from an outside firm offers a great teaching opportunity and enhances our skillset as a business.”
This brings us to financing models. I was interested to know how Mike set up agreements with partners, and what his philosophy was on fixed term outcomes versus taking accountability for owning the outcome.
“No matter how many conversations you have upfront, you’re never going to scope out everything when outsourcing. That is fundamentally against how agile development functions. I think managing general timelines, being transparent about costs and the run rate is key.”
Internal financing models are equally as important, and I chatted with Mike about how his company again took a holistic approach.
“Every department wants their piece. The company considers which two projects are the most important, and where the money will go. Any overflow can then go to the third most important.”
Mike thinks that this type of decision-making demonstrates a growing maturity in the decision practices his company has begun employing in the last few years. A democratic approach to deciding what the organisation is working on leads to harmony and a smoother operation.
Successfully delivering and supporting a customer-based technology vision and strategy is no easy task. The balance between maintenance, development and managing the teams responsible for these is crucial. Do you prioritise development over maintenance? Or is your team dependent on external sources? These are significant factors in contributing to the success of a platform. The mantra that Mike and I both agree upon, is that standing still is not an option.