Many projects fail because tech partners use heroic tactics to solve problems nobody signed up to solve, or that did not include the main stakeholder in a true spirit of service. The missing agreement belongs at the beginning of the project.
Make the core question whether the model should have been built, before asking whether it was accurate or who maintains it. Ask whether the actual function accountable for the subject requested the model and meaningfully helped define the problem.
The question before the forecast
Jeffrey D. Camm, Michael J. Fry and Scott M. Shafer open their MIT Sloan Management Review article with a hypothetical retailer. Its data science team produces accurate demand predictions, but the operations manager still cannot answer the CEO's question about how much inventory to hold and where. The authors argue for connecting analytics to the decisions managers actually face.
That example raises an earlier question for me: what agreement led the team to build the forecast? The article's opening does not establish who requested it or how the accountable function participated. The authors later recommend starting projects with a decision brief. I would use that brief to establish the accountable function's mandate, including its role in choosing the problem.
For an inventory model, functional ownership means involving the people accountable for inventory decisions and their consequences. The authors note that producing too much and too little can carry very different costs. The function needs to help define the tradeoffs and what change it is prepared to make if the analysis proves useful.
Functional ownership must shape the work before delivery begins; a sponsor or technical owner does not substitute for the accountable stakeholder. The function also needs a real say in whether a model is needed. Its problem may call for a clearer operating rule, a process change, or better use of information it already has. Choosing a model before understanding the problem can turn discovery into a search for reasons to justify the build.
Partnership starts with service
Technology partners can propose ideas proactively, but should develop them with the main stakeholder in a true spirit of service. They may see an opportunity the function has not articulated, or a capability its people do not know exists. Requiring a perfectly written request before offering help would be a poor form of partnership. The responsibility is to take that idea to the accountable stakeholder and develop the problem together before committing to delivery.
Start by understanding which decision is difficult and why the current approach has persisted. The stakeholder should be able to challenge the proposed solution, change its scope, or decide that a different problem deserves attention first. A conversation that leaves those choices closed asks for endorsement after the technical team has already decided what matters.
Before approving the build, I would ask that stakeholder to describe the problem in their own terms and explain why this proposed work deserves priority. Then agree on the decision to improve and the evidence that would justify changing it. The data team remains accountable for technical quality; the function retains accountability for the operational decision. Both need to understand what they are committing to.
That agreement must leave room to stop. If the function does not recognize the problem, cannot support the change, or concludes that a simpler response would serve it better, the team should reconsider the model. Finding that out early is useful work, even when it produces no model to demonstrate.
Sources
- Why Data Modeling Is Not Enough, MIT Sloan Management Review