3. Stakeholder and Executive Expectations Management in Iterative Development
Discussion and methods for stakeholder and executive expectations management during iterative development.
Iterative development vs. business. How do we as an industry still tackle it wrongly most often? Where is the trust in real iterations?
This article focuses on stakeholder and executive expectations management during iterative development and it’s partly a continuation post to my post about iterative game development (see more: https://gamesalchemy.substack.com/p/2-get-iterative-game-development):
Business vs. Real and True Iterative Development
Overall, trying to keep it a bit shorter this time; if we would follow right type of iterative approach, we shouldn't limit ourselves with the constraints of business too much. Yet, we do that by setting strict timelines, deadlines, budgets, and such — and, sometimes, even set in place strict game design documents, and similar things, to be followed madly beyond true iterative means. What is set in place, in this context, it is usually done by management, or team in collab. with management.
Real and true iterative development doesn't really work in the context of what I mention above, if those things are set wrongly in place — especially if you really think about approaching things through the true 'soul' of iterative development and the mindset around it. Both management and team should understand this and operate fluently on this side.
Those who understand, understand.
Those who don't: you can start from e.g., my article about iterative development (see above links), which can be found from my Substack. Over time, the more you work in the industry and around different cultures, and learn over these things, you will understand what I’m after — the day will come when you get what I’m writing here.
Obviously, I get all the business side of things here and why we operate sometimes as we do — starting from delivering results within certain timelines, spending money ‘wisely’, and so on. This is just how the world operates; even though, it forces pushes in the end that are more about staying within a timeline and budget vs. being open for iterations until the end of the milestone. Here, specifically, we should trust more in iterative development and mindset on things — as if done right, it also results to great outcomes and business, and in most cases budgets (and potentially, as you would get there, P&Ls) will thank you quite a lot, in terms of how money gets spend more wisely and lean way, and overall how success gets built when things compound together the right way.
Trust on iterative development definitely starts from the top. But, it's not always even up to the top — like even staff-level developers, artists, etc. need to understand and touch the waters on it the right way. If waters are touched the right way, even a startup with limited budget can iterate in the way iterative development should be done.
Expectations Management Solutions
I have myself looked on different means, and found some ways to navigate throughout the waters here, but on top of that (and to make interactions here on my Substack over time with my readers) I would love to learn more openly from industry peers here and my network about this side of things. So, I would love to hear everyone's thoughts on this front and how you have tackled these layers.
Moving towards solutions, overall I think there are couple to be looked into:
Full Trust Model.
Min.-Max. Model.
Full Trust Model
Full trust model basically gives full trust for the team over their game(s), where stakeholders and executives are having full buy-in for what the team is doing and how they’re doing and iterating things.
This would be in many cases an ideal model, if the team can manage its own budget, P&L, and timeline — as well as ship games with right way throughout proper iterative means, which would lean towards building successful product(s). This model would suit even for hyper and hybrid casual studios, when enabled right, as even a scientific process can be build over iterative means and trust.
To have something like this is place, indeed, lots of trust would be required — and, potentially, coaching for arguing why iterative development should be proceeded properly vs. bearing the risks less iterative models have.
Min.-Max. Model
Min.-Max. Model is a model that I see as a win-win vs. win-lose, where both the stakeholders / executives and the team gets their win. This includes some roles and responsibilities on the setup being shared between ‘both sides’ where also budgets, timelines, and P&L are used and in place; in an agreed manner, with a joint agreement.
The way, how timelines, budgets, and such are used, and are in place, is based on a timeline that is set for the game’s roadmap and development plan, which follows a min.—max. timeline (/deadline) and budget (both timeline and budget agreed between stakeholders / executives and the team) the team manages and is responsible for.
In terms of how this works with iterative game development, overall the team has ownership (and is of course accountable for) for their minimum as well as maximum timeline and budget usage, under which they can build (/pivot or /kill as well) their game and base their iterative development towards to — meaning, they constantly get to practice shipping the game within the min.—max. range and ask a question: “Is our game ready yet?”. If the answer is yes and goals are met, then you ship it / the current stage. If the answer is no, then you iterate one step further and repeat this question, whilst try to spend your timeline (and budget) wisely in terms of where the max. point is set up.
Of course, this model is not the most ideal one, but it gives some ways to iterate with shipping in mind vs. going with the traditional model for iterative development, which doesn’t kind of push team for asking readiness of the product early on. This is kind of a bridged model, I’d say — and it is better than nothing.
Final Thoughts
What else there is? Again, as stated above, would love to hear more from you industry folks!
Obviously, I know that there are models where you just try to buy enough time for your team, to get iterative development right, and hope for the best — and/or fight for survival (sometimes in Hunger Games style) with stakeholders / executives as (/if) the realities hit ‘both sides’. It’s, though, not really ideal overall, when you could approach things more healthier way — and this is where I hope my suggested two models can come handy for some.
Overall, I believe, those presented models can work in any type of organization and/or development management setting — from indie games development to developing games under a publicly listed company. For the latter, obviously, I get that the Full Trust Model can be tricky, but this is where Min.-Max. Model could work better vs. promising a deadline that won’t be met (sometimes, as the case can be — and we’ve seen happening) with right quality and KPIs in place.
Coaching your shareholders can be tricky for something like Full Trust Model, but Min.-Max. Model here also could be more sense-making if these things are communicated more openly and publicly. I can also see, a Full Trust Model in disguise working, where you safeguard iterative means so that public announcements are made only when the case is 100% sure to be working — but depending of the company and its capacity, this can be tricky for periods of time if things take time for getting them right.
Extra Tips
In terms of expectations management towards your executives and/or stakeholders, they would most likely appreciate if you would follow proper Business Modeling and Benchmarking practices.
Find more about Business Modeling here (https://gamesalchemy.substack.com/p/6-why-business-modeling-your-f2p):
More about Benchmarking here (https://gamesalchemy.substack.com/p/7-early-stage-benchmarking):
Happy navigating in the world of expectations management!