ज़्यादातर AI बजट फेल होने से नहीं जाते। वे उस प्रोजेक्ट में जाते हैं जो कभी पूरा ही नहीं होता — इतना उम्मीद भरा कि फंडिंग चलती रहे, कभी इतना अच्छा नहीं कि डिप्लॉय हो सके। इसका इलाज ढाँचे में है: पहला बिल आने से पहले एग्ज़िट कंडीशन तय कर लें।
सिस्टम को नहीं, एक सवाल को फंड करें
पहले फेज़ को एक ही सवाल का जवाब देना चाहिए: क्या यह इस साइट पर, इस एक्युरेसी पर, ऐसी लागत में मुमकिन है जो समझ में आती हो? वह फेज़ छोटा हो, समय-सीमा में बँधा हो, और उसे "नहीं" कहने की छूट हो।
सफलता का नंबर पहले लिखें
काम शुरू होने से पहले मेट्रिक, टारगेट और स्वीकार्य फॉल्स-अलार्म रेट लिखें। जो व्यक्ति सिस्टम इस्तेमाल करेगा, उससे इस पर सहमति लें। नतीजे देखने के बाद तय हुआ टारगेट टारगेट नहीं होता, वह मोलभाव होता है।
- क्या डिटेक्ट या प्रेडिक्ट किया जा रहा है, एक वाक्य में
- काम का होने के लिए कितनी एक्युरेसी चाहिए, नंबर में
- ऑपरेटर कितना फॉल्स-अलार्म रेट बर्दाश्त करेंगे
- सिस्टम अलर्ट देने पर ऑपरेटर क्या करता है
- वह तारीख जब जारी रखने या रोकने का फैसला होगा
डेटा के काम का बजट रखें, क्योंकि काम ज़्यादातर वही है
कलेक्शन, क्लीनिंग और लेबलिंग अक्सर मॉडलिंग से ज़्यादा समय खाते हैं। जो प्लान बजट का बड़ा हिस्सा मॉडल डेवलपमेंट को देता है, वह ऐसे प्रोजेक्ट की बात कर रहा है जो पहले कभी नहीं हुआ।
पायलट की लागत और चलाने की लागत अलग रखें
पायलट वाला नंबर मंज़ूर होता है और चलाने वाला नंबर तकलीफ़ देता है। दोनों शुरू में ही माँगें: हार्डवेयर रिफ्रेश, होस्टिंग, मॉनिटरिंग, रीट्रेनिंग, सपोर्ट। जो वेंडर आपको पाँच साल की रन कॉस्ट नहीं दे सकता, उसने पहले ऐसा सिस्टम बनाया नहीं है।
किसी प्रपोज़ल का सबसे कीमती वाक्य वह है जो बताता है कि पायलट टारगेट से चूक गया तो क्या होगा। अगर वह नहीं है, तो लिखित में माँगें।
एक भद्दे शुरुआती डेमो पर अड़े रहें
तीसरे हफ्ते का कच्चा चलता हुआ वर्ज़न, तीसरे महीने के चमकदार डेक से ज़्यादा बताता है। वह असली फेलियर मोड जल्दी दिखा देता है, जब बजट और समय दोनों बचे होते हैं।
हैंडओवर की योजना पहले दिन से बनाएँ
गो-लाइव के बाद इसका मालिक कौन है, इसे रीट्रेन कौन करेगा, और साथ में क्या डॉक्युमेंटेशन आएगा। जिस सिस्टम को आपके संगठन में कोई चला नहीं सकता, वह ऐसेट नहीं, सब्सक्रिप्शन है।