অনবোর্ডিং কলে কোন প্রশ্ন করলে বাস্তবায়ন দ্রুত হয়

কল শেষ হলো। সবাই পরবর্তী কাজ নিয়ে মোটামুটি একমত। কিন্তু কয়েক ঘণ্টা পর প্রকল্প ব্যবস্থাপক বুঝলেন—প্রশাসনিক প্রবেশাধিকার কে দেবে জানা নেই, তথ্য কোন বিন্যাসে আসবে সেটি ঠিক হয়নি, আর চূড়ান্ত অনুমোদন কার কাছ থেকে নিতে হবে সেটিও পরিষ্কার নয়।

এই জায়গাতেই অনেক অনবোর্ডিং ধীর হয়ে যায়।

একটি গ্রাহক অনবোর্ডিং কলের উদ্দেশ্য যত বেশি প্রশ্ন করা সম্ভব তত বেশি প্রশ্ন করা নয়। বরং বৈঠক শেষ হওয়ার পর কাজ শুরু করতে যে তথ্যগুলো সত্যিই দরকার, সেগুলো পরিষ্কার করা। কিছু উত্তর তখনই পাওয়া যাবে। কিছু উত্তর পরে আসবে। কিন্তু দ্বিতীয় ক্ষেত্রে অন্তত জানা থাকা উচিত—উত্তরটি কে দেবেন এবং কবে দেবেন।

প্রকল্প ব্যবস্থাপক, গ্রাহক সাফল্য ব্যবস্থাপক, সংস্থা বা ব্যবসা-থেকে-ব্যবসা সেবাদাতা দলের জন্য তাই একটি ভালো অনবোর্ডিং কল অনেকটা কাজ শুরুর প্রস্তুতি যাচাইয়ের মতো।

কলের আগে যেটুকু জানা যায়, বৈঠকে সেটি আবার জিজ্ঞেস করবেন না

অনবোর্ডিং কলের সময় সীমিত। সেই সময় প্রতিষ্ঠানের নাম, ওয়েবসাইট, যোগাযোগের তথ্য বা আগে থেকেই প্রস্তাবনায় থাকা তথ্য পুনরায় সংগ্রহে ব্যয় করার খুব বেশি অর্থ নেই।

প্রাথমিক তথ্য আগে প্রশ্নমালা বা ফরমে নেওয়া যায়। যেমন:

• মূল যোগাযোগ ব্যক্তি;
• বর্তমান ওয়েবসাইট বা প্ল্যাটফর্ম;
• ব্যবহৃত সফটওয়্যার;
• আগে থেকে থাকা উপকরণ;
• সংশ্লিষ্ট দল;
• প্রয়োজনীয় সংযোগ সম্পর্কে প্রাথমিক তথ্য।

বিক্রয়-পরবর্তী হস্তান্তর নথি, প্রস্তাবনা, চুক্তি বা কাজের বিবরণী আগে পাওয়া থাকলে কলের আগে সেগুলোও দেখে নেওয়া ভালো।

তারপর প্রশ্নটিকে আরেকটু নির্দিষ্ট করা যায়।

“আপনার অগ্রাধিকার কী?” জিজ্ঞেস করার বদলে বলা যায়:

“প্রস্তাবনায় তিনটি অগ্রাধিকার আছে। প্রথম পর্যায়ে কোনটির ফল সবচেয়ে আগে দেখতে চান?”

একই তথ্য দ্বিতীয়বার নেওয়া আর আগের তথ্য ধরে সিদ্ধান্তের দিকে এগোনো—দুটির মধ্যে পার্থক্য এখানেই।

প্রথমে জানতে হবে, গ্রাহক আসলে কী বদলাতে চাইছেন

“আপনার লক্ষ্য কী?” খুব পরিচিত প্রশ্ন। কিন্তু এর উত্তরও প্রায়ই খুব সাধারণ হয়।

“বিক্রি বাড়াতে চাই।”

“কাজের প্রক্রিয়া সহজ করতে চাই।”

“ওয়েবসাইট ভালো করতে চাই।”

এগুলো দিক নির্দেশ করে, কিন্তু বাস্তবায়ন পরিকল্পনা বানানোর জন্য যথেষ্ট নাও হতে পারে।

বরং ফলাফলটি একটু কাছ থেকে ধরুন।

নতুন গ্রাহক সম্পর্ক ব্যবস্থাপনা ব্যবস্থা চালু হলে বিক্রয় দল কোন কাজটি আগের চেয়ে সহজে করতে পারবে? ওয়েবসাইট নতুনভাবে সাজানো হলে সবচেয়ে গুরুত্বপূর্ণ ফল কোনটি—সম্ভাব্য গ্রাহক সংগ্রহ, বুকিং, কেনাকাটা, নাকি তথ্য সহজে খুঁজে পাওয়া?

তারপর আরেকটি প্রশ্ন আসে:

প্রথম পর্যায় শেষে কোন এক বা দুইটি ফলাফল না এলে প্রকল্পটিকে পিছিয়ে আছে বলে মনে হবে?

এই প্রশ্নটির মূল্য আছে, কারণ সব লক্ষ্য একই সময়ে প্রথম অগ্রাধিকার হতে পারে না। প্রথম পর্যায়ের কাজ আর পরে করা যাবে এমন কাজ আলাদা করতে না পারলে কাজের পরিধি খুব সহজেই বেড়ে যায়।

কাজের পরিধি নিয়ে “আমরা তো ভেবেছিলাম…” বাক্যটি যেন পরে না আসে

অনেক প্রকল্পে বড় সমস্যা প্রযুক্তিগত নয়; দুই পক্ষ একই শব্দের আলাদা অর্থ ধরে নেয়।

“ওয়েবসাইট নতুনভাবে সাজানো” তার সহজ উদাহরণ।

সেবাদাতা হয়তো নকশা ও উন্নয়ন বুঝেছেন। গ্রাহক ধরে নিয়েছেন এর মধ্যে লেখার কাজ, সার্চ ইঞ্জিন অপটিমাইজেশন স্থানান্তর, পরিমাপব্যবস্থা স্থাপন এবং হোস্টিং পরিবর্তনও আছে।

তাই কাজের পরিধি নিয়ে খুব সরাসরি কথা বলা ভালো:

• এই পর্যায়ে কোন কাজ বা ফলাফল নিশ্চিতভাবে অন্তর্ভুক্ত?
• কোন কাজটি এর বাইরে?
• নতুন কোনো অনুরোধ এলে কখন সেটিকে কাজের পরিধির পরিবর্তন হিসেবে ধরা হবে?

প্রকল্পের পরিধি শুধু কী করা হবে তার তালিকা নয়। কী করা হবে না, সেটিও সমান দরকারি। বড় প্রকল্প হলে নতুন পরিবর্তনের অনুরোধ কীভাবে নেওয়া হবে, সেটাও আগে ঠিক করে রাখা যায়। এখানে একটু অস্বস্তিকর আলোচনা শুরুতেই হওয়া বরং ভালো। চালুর এক সপ্তাহ আগে কাজের পরিধি নিয়ে তর্ক হওয়ার চেয়ে শুরুর বৈঠকে পাঁচ মিনিট বেশি কথা বলা সহজ।

নতুন ব্যবস্থা বসানোর আগে পুরোনো কাজের পথটি বুঝুন

গ্রাহক কী চান সেটি জানার পর দেখতে হবে কাজটি এখন কীভাবে হচ্ছে।

ধরা যাক নতুন স্বয়ংক্রিয় ব্যবস্থা বসানো হবে। তার আগে জানতে হবে:

• সম্ভাব্য গ্রাহকের তথ্য কোথা থেকে আসে?
• কে পর্যালোচনা করেন?
• তথ্য কোথায় জমা হয়?
• কোন ধাপে হাতে কাজ বেশি?
• কোন কাজটি অন্য ব্যবস্থা বা দলের ওপর নির্ভর করে?

এই প্রশ্নগুলোর উত্তর না জেনে নতুন কাজের ধারা আঁকলে এমন একটি প্রক্রিয়া তৈরি হতে পারে, যা কাগজে সুন্দর কিন্তু বাস্তবে গ্রাহকের বর্তমান ব্যবস্থার সঙ্গে ঠিকমতো মেলে না। বিশেষ করে সফটওয়্যার-ভিত্তিক সেবা, গ্রাহক সম্পর্ক ব্যবস্থাপনা, তথ্য বিশ্লেষণ, অনলাইন বাণিজ্য বা তথ্যভিত্তিক প্রকল্পে বিভিন্ন ব্যবস্থার সংযোগের জায়গাটি শুরুতেই দেখা দরকার।

• অন্য কোনো প্ল্যাটফর্মের সঙ্গে সংযোগ লাগবে কি?
• অ্যাপ্লিকেশন প্রোগ্রামিং ইন্টারফেসের প্রবেশাধিকার প্রয়োজন কি?
• ডোমেইন বা ডোমেইন নাম ব্যবস্থা পরিবর্তন করতে হবে?
• পেমেন্ট গেটওয়ে জড়িত?
• তথ্য সংরক্ষণাগার আছে?
• কোনো তৃতীয় পক্ষের সেবাদাতার সাহায্য ছাড়া একটি ধাপ এগোবে না?

এখানে প্রতিটি নির্ভরতার পাশে দুটি তথ্য লিখে রাখলে পরে সুবিধা হয়—দায়িত্বে কে এবং কখন সেটি প্রয়োজন।

“প্রবেশাধিকার লাগবে” যথেষ্ট নয়—কোন প্রবেশাধিকার, কার কাছ থেকে, কখন?

অনেক প্রকল্পের শুরুর বৈঠক ভালো হয়, প্রযুক্তিগত দলও প্রস্তুত থাকে, তারপর কাজ থেমে থাকে একটি প্রবেশাধিকার বা তথ্য রপ্তানির জন্য।

তাই “প্রবেশাধিকার লাগবে” লিখে থেমে যাবেন না।

• কোন অ্যাকাউন্ট?
• কোন ফোল্ডার?
• কোন নিয়ন্ত্রণপ্যানেল?
• কোডভান্ডারে প্রবেশাধিকার লাগবে?
• তথ্য রপ্তানি কে দেবেন?
• ব্র্যান্ডের উপকরণ কোথায় আছে?

প্রথম কাজ শুরু করার আগে যেগুলো না থাকলে দল আটকে যাবে, সেগুলো আলাদা করে চিহ্নিত করুন। তথ্য স্থানান্তর থাকলে আরও কিছু প্রশ্ন দরকার হতে পারে—ফাইলের বিন্যাস কী, কত দিনের তথ্য লাগবে, তথ্যক্ষেত্রের মিল কে দেখবেন, তথ্যের মান নিয়ে আগে থেকে কোনো সমস্যা জানা আছে কি না।

প্রবেশাধিকার ও গোপন তথ্য ব্যবস্থাপনায় অবশ্যই আলাদা সতর্কতা দরকার। পাসওয়ার্ড বা অন্য প্রবেশ-তথ্য সাধারণ বৈঠকের নোট, স্প্রেডশিট বা সবার প্রবেশাধিকার আছে এমন নথিতে সরাসরি লেখা উচিত নয়। প্রতিষ্ঠানের অনুমোদিত পাসওয়ার্ড ব্যবস্থাপক, নিরাপদ পরিচয়পত্র ভান্ডার বা অন্য সুরক্ষিত পদ্ধতি ব্যবহার করা ভালো। প্রয়োজন অনুযায়ী বহুধাপ যাচাইকরণও রাখা যেতে পারে।

যিনি কলে আছেন, তিনিই কি সিদ্ধান্ত দিতে পারবেন?

এটি শুরুতেই জানা দরকার।

গ্রাহকের সঙ্গে নিয়মিত কথা বলছেন যে ব্যক্তি, তিনিই বাজেট, কাজের পরিধি বা চূড়ান্ত অনুমোদন দিতে পারবেন—এমন কোনো নিশ্চয়তা নেই।

তাই আলাদা করে বুঝুন:

• দৈনন্দিন যোগাযোগ করবেন কে?
• প্রযুক্তিগত প্রশ্ন এলে কার কাছে যাবেন?
• চূড়ান্ত অনুমোদন কে দেবেন?
• বাজেট বা কাজের পরিধি বদলালে সিদ্ধান্ত কার?

জটিল প্রকল্পে দায়িত্ব ভাগ করতে রেসি কাঠামো ব্যবহার করা যায়। এতে চার ধরনের ভূমিকা আলাদা করা হয়—কাজের দায়িত্বে থাকা ব্যক্তি, চূড়ান্ত দায় বহনকারী, পরামর্শদাতা এবং যাঁকে তথ্য জানাতে হবে।

তবে ছোট অনবোর্ডিংয়ের জন্য পূর্ণাঙ্গ রেসি ছক বানানো সব সময় প্রয়োজন হয় না।

অনেক ক্ষেত্রে দুটি নাম জানাই যথেষ্ট: কাজের দায়িত্বে কে, আর সিদ্ধান্ত দেবেন কে।

এই জায়গায় অতিরিক্ত কাঠামো ব্যবহার করলে অনবোর্ডিং সহজ হওয়ার বদলে আরও ভারীও হয়ে যেতে পারে।

অনুমোদন কোন ধাপে আটকে যেতে পারে, সেটাও জিজ্ঞেস করুন

“নকশা কে অনুমোদন করবেন?” জানাই যথেষ্ট নয়। অনুমোদনের আগে আর কার পর্যালোচনা প্রয়োজন, সেটিও জানতে হবে। কোনো প্রকল্পে ব্র্যান্ড দল থাকতে পারে। কোথাও তথ্যপ্রযুক্তি বিভাগের অনুমোদন লাগতে পারে। কোথাও আইন, অর্থ বা ক্রয় বিভাগ যুক্ত হবে।

এগুলো প্রকল্পের ধরন ও প্রতিষ্ঠানের ওপর নির্ভর করে। তাই সবার জন্য একই অনুমোদনপ্রক্রিয়া ধরে নেওয়া ঠিক নয়।

কিন্তু একটি বিষয় পরিষ্কার: এমন কোনো পর্যালোচক যদি পরে এসে নতুন শর্ত দেন, সময়সূচি বদলাতে পারে। ফলে যাঁর মতামত সত্যিই প্রয়োজন, তাঁকে কোন পর্যায়ে যুক্ত করা হবে সেটি শুরুর বৈঠকেই বোঝা ভালো।

আরও পড়ুন: SaaS Onboarding কী: Signup-এর পর User-কে দ্রুত Value দেখানোর কৌশল

“যত দ্রুত সম্ভব” কোনো সময়সীমা নয়

গ্রাহক যদি বলেন, “এটা খুব দ্রুত দরকার,” পরের প্রশ্ন হওয়া উচিত—কোন তারিখটি আসলে নড়বে না?

• চালু করা কি কোনো প্রচারণার সঙ্গে যুক্ত?
• কোনো অনুষ্ঠান আছে?
• চুক্তি নবায়ন?
• পণ্য প্রকাশ?
• প্রশিক্ষণ অধিবেশন?

যে সময়সীমা সত্যিই স্থির, সেটি জানা গেলে কাজের পরিধি বা কাজের ক্রম বাস্তবভাবে সাজানো যায়। শুধু চূড়ান্ত চালুর তারিখ লিখলেও সমস্যা আছে। মাঝখানের ধাপ না থাকলে প্রকল্প শেষ মুহূর্ত পর্যন্ত ঠিক পথে আছে কি না বোঝা কঠিন হতে পারে।

প্রয়োজনে আলাদা তারিখ রাখুন:

তথ্য হস্তান্তর;

প্রাথমিক বিন্যাস;

পর্যালোচনা;

পরীক্ষা;

অনুমোদন;

প্রশিক্ষণ।

সব প্রকল্পে সব ধাপ লাগবে না। প্রয়োজন নেই এমন ধাপ শুধু তালিকা পূরণের জন্য যোগ করারও দরকার নেই।

গ্রাহকের কাজও প্রকল্প পরিকল্পনার অংশ

অনবোর্ডিং পরিকল্পনায় শুধু নিজের দলের কাজ থাকলে প্রকল্পের অর্ধেক নির্ভরতা চোখের বাইরে থেকে যেতে পারে।

গ্রাহকের কাছ থেকেও কাজ আসতে পারে:

অ্যাকাউন্টে প্রবেশাধিকার দেওয়া;

তথ্য রপ্তানি পাঠানো;

ব্র্যান্ডের প্রয়োজনীয় উপকরণ পাঠানো;

সংযোগ অনুমোদন করা;

খসড়া পর্যালোচনা করা;

মতামত দেওয়া;

চূড়ান্ত অনুমোদন দেওয়া।

এগুলোর মধ্যে যেটি আপনার পরবর্তী কাজ আটকে দিতে পারে, তার পাশে দায়িত্বপ্রাপ্ত ব্যক্তি ও নির্ধারিত তারিখ রাখুন।

“গ্রাহক পাঠাবে” কোনো দায়িত্বপ্রাপ্ত ব্যক্তির নাম নয়।

“রাহিম, বৃহস্পতিবারের মধ্যে বিশ্লেষণ ব্যবস্থার প্রবেশাধিকার দেবেন”—এটি ব্যবহারযোগ্য কাজের নির্দেশনা।

এই ছোট পার্থক্যই পরবর্তী যোগাযোগ অনেক পরিষ্কার করে।

নিরাপত্তা বা গোপনীয়তা যাচাই শেষ সপ্তাহে আবিষ্কার করা ঠিক নয়

গ্রাহকের তথ্য, অর্থপ্রদানের তথ্য, গোপন ব্যবসায়িক তথ্য বা সংবেদনশীল ব্যবস্থা জড়িত প্রকল্প হলে শুরুতেই জেনে নিন গ্রাহকের কোনো নিরাপত্তা বা গোপনীয়তা যাচাইপ্রক্রিয়া আছে কি না।

• সেবাদাতার নিরাপত্তা যাচাই করতে হবে?
• নিরাপত্তা প্রশ্নমালা আছে?
• ব্যবস্থায় প্রবেশাধিকার দেওয়ার আগে তথ্যপ্রযুক্তি বিভাগের অনুমোদন দরকার?
• তথ্য ব্যবস্থাপনা নিয়ে আইন বা গোপনীয়তা পর্যালোচনা হবে?

এর কোনো একটিই সবার জন্য বাধ্যতামূলক নয়। প্রতিষ্ঠানের নীতি, প্রকল্প এবং তথ্যের ধরন অনুযায়ী প্রয়োজন বদলাবে। এই কারণেই সাধারণ অনবোর্ডিং তালিকা হুবহু ব্যবহার করার চেয়ে গ্রাহকের নিজস্ব প্রক্রিয়া সম্পর্কে জিজ্ঞেস করা বেশি কার্যকর।

ব্যবস্থা চালু করলেই অনবোর্ডিং শেষ হয় না

সফটওয়্যার বা ব্যবস্থা প্রযুক্তিগতভাবে চালু হয়েছে—এটুকু দিয়ে বাস্তবায়ন শেষ ধরে নেওয়া সব প্রকল্পে ঠিক হবে না।

• প্রশাসক কী করবেন?
• ব্যবস্থাপকের কী জানা দরকার?
• শেষ ব্যবহারকারী কোন কাজটি নিজে করতে পারবেন?
• প্রশিক্ষণ সরাসরি হবে, ধারণকৃত ভিডিও হবে, নাকি লিখিত নির্দেশনাই যথেষ্ট?

ভূমিকা অনুযায়ী প্রশিক্ষণের প্রয়োজন ভিন্ন হতে পারে। তাই প্রশিক্ষণ প্রয়োজন কি না, থাকলে কার জন্য—এটি পরিকল্পনার অংশেই রাখা ভালো। অন্যথায় ব্যবস্থা প্রযুক্তিগতভাবে প্রস্তুত হলেও হস্তান্তরের সময় নতুন ঘাটতি দেখা দিতে পারে।

ঝুঁকি নিয়ে সরাসরি প্রশ্ন করুন

সব গ্রাহক নিজে থেকে প্রকল্পের ঝুঁকির তালিকা দেবেন না। প্রশ্ন করতে হতে পারে।

• আগের সেবাদাতা সময়সীমা মিস করেছিল?
• আগের তথ্য স্থানান্তরে সমস্যা হয়েছিল?
• অভ্যন্তরীণ দলের সময় কম?
• কোনো গুরুত্বপূর্ণ অনুমোদন এখনো অনিশ্চিত?
• কোনো তৃতীয় পক্ষের সেবাদাতার উত্তরের ওপর প্রকল্প চালু হওয়া নির্ভর করছে?

যে ঝুঁকি আগে থেকেই জানা, অন্তত সেটির দায়িত্বপ্রাপ্ত ব্যক্তি ও সম্ভাব্য করণীয় নিয়ে কথা বলা যায়।

আর বৈঠক শেষ করার আগে একটি প্রশ্ন বাদ দেবেন না:

“এই কল শেষ হওয়ার পর প্রথম কাজটি কী?”

সেটি প্রবেশাধিকার চাওয়া হতে পারে। নমুনা তথ্য পাঠানো হতে পারে। প্রযুক্তিগত যাচাই হতে পারে। প্রকল্পের কাজের জায়গা তৈরি করাও হতে পারে। কাজটির নামের চেয়ে বেশি গুরুত্বপূর্ণ হলো—কে করবেন এবং কখন করবেন।

৪৫–৬০ মিনিটে কল সাজাতে চাইলে

সব গ্রাহক অনবোর্ডিং কলের জন্য একই সময় নির্ধারণের প্রয়োজন নেই। ছোট, সরল প্রকল্পের শুরুর বৈঠক অল্প সময়েই শেষ হতে পারে। অনেক অংশীজন ও প্রযুক্তিগত নির্ভরতা থাকলে বেশি সময় লাগবে।

মাঝারি জটিলতার প্রকল্পের জন্য ৪৫–৬০ মিনিটের একটি আলোচনাসূচি এভাবে সাজানো যেতে পারে:

এটি কোনো শিল্পখাতের বাধ্যতামূলক মান নয়।

প্রযুক্তিগত বাস্তবায়নে সংযোগ ও প্রবেশাধিকার নিয়ে বেশি সময় লাগতে পারে। সংস্থা বা সেবাভিত্তিক প্রকল্পে কাজের পরিধি, উপকরণ হস্তান্তর বা অনুমোদন নিয়ে কথাই বেশি হতে পারে। আলোচনাসূচি প্রকল্পের সঙ্গে মিলিয়ে ছোট-বড় করুন। পূর্বনির্ধারিত ছকের সঙ্গে প্রকল্পকে জোর করে মেলানোর প্রয়োজন নেই।

কল শেষ হওয়ার পর আরেক দফা বিভ্রান্তি তৈরি করবেন না

বৈঠক শেষে পুরো কথোপকথনের লিখিত প্রতিলিপি পাঠানোর চেয়ে কাজের জন্য দরকারি সিদ্ধান্তগুলো সহজে খুঁজে পাওয়া বেশি গুরুত্বপূর্ণ।

লিখে রাখুন:

• কী সিদ্ধান্ত হয়েছে;
• কোন প্রশ্ন এখনো খোলা;
• পরবর্তী কাজ কী;
• দায়িত্বে কে;
• সময়সীমা কী;
• পরবর্তী গুরুত্বপূর্ণ ধাপ কোনটি;
• কোন নির্ভরতা কাজ আটকে রেখেছে।

সবচেয়ে ভালো জায়গা হলো দল যে প্রকল্প ব্যবস্থাপনার জায়গাটি সত্যিই ব্যবহার করে, সেখানে এই তথ্য রাখা। বৈঠকের নোট এক জায়গায়, করণীয় আরেক জায়গায়, অনুমোদনের ই-মেইল অন্য জায়গায় থাকলে পরে আবার তথ্য খুঁজতে সময় যায়। ছোট প্রতিষ্ঠানে আলাদা তথ্যপ্রযুক্তি, ক্রয় বা পরিচালন দল নাও থাকতে পারে। তখন বিভাগের নাম ধরে প্রশ্ন না করে দায়িত্ব ধরে জিজ্ঞেস করা বেশি স্বাভাবিক।

“এই অ্যাকাউন্টের প্রশাসক কে?”

“খরচ অনুমোদন করবেন কে?”

“চূড়ান্ত লেখা কে দেখবেন?”

অন্যদিকে বড় বাস্তবায়নে অংশীজন, নিরাপত্তা যাচাই, বিভিন্ন ব্যবস্থার সংযোগ এবং তথ্যসংক্রান্ত নির্ভরতা অনেক বেশি হতে পারে। তাই অনবোর্ডিং কতটা বিস্তারিত হবে, সেটি শুধু প্রতিষ্ঠানের আকার দেখে ঠিক করা উচিত নয়। প্রকল্প আসলে কতটা জটিল, সেটিই বেশি গুরুত্বপূর্ণ।

পরের গ্রাহক অনবোর্ডিং কলের আগে একটি কাজ করুন

আরও বড় প্রশ্নমালা বানানোর আগে আপনার আগের কয়েকটি প্রকল্পের দেরির জায়গাগুলো দেখুন।

• কাজ কোথায় আটকে ছিল?
• প্রবেশাধিকার?
• অনুমোদন?
• কাজের পরিধি?
• তথ্য?
• তৃতীয় পক্ষের ওপর নির্ভরতা?
• সিদ্ধান্তদাতা?

তারপর এই নিবন্ধের প্রশ্নগুলোর মধ্যে যেগুলো সেই ধরনের দেরি আগে ধরতে পারত, সেগুলো আপনার অনবোর্ডিং তালিকায় রাখুন। একটি গ্রাহক অনবোর্ডিং কল সব ধরনের বাস্তবায়ন বিলম্ব বন্ধ করতে পারবে না। প্রযুক্তিগত সমস্যা হতে পারে, সেবাদাতা দেরি করতে পারে, গ্রাহকের অভ্যন্তরীণ অনুমোদন আটকে যেতে পারে।

কিন্তু কল শেষে যদি দল জানে কী করতে হবে, কার কাছ থেকে কী লাগবে এবং কোন উত্তর এখনো বাকি, তাহলে অন্তত এড়ানো সম্ভব এমন বিভ্রান্তি নিয়ে প্রকল্প শুরু করতে হয় না। বৈঠকের কার্যকারিতা মাপার জন্য সেটিই সবচেয়ে ব্যবহারিক পরীক্ষাগুলোর একটি।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

গ্রাহক অনবোর্ডিং কলের আগে কী কী তথ্য সংগ্রহ করা উচিত?

প্রতিষ্ঠানের মৌলিক তথ্য, মূল যোগাযোগ ব্যক্তি, ব্যবহৃত সফটওয়্যার, বর্তমান ওয়েবসাইট বা প্ল্যাটফর্ম, বিদ্যমান উপকরণ এবং সম্ভাব্য প্রযুক্তিগত সংযোগের তথ্য আগে সংগ্রহ করা যায়। প্রস্তাবনা, চুক্তি বা কাজের বিবরণী থাকলে সেগুলোও আগে দেখে নেওয়া ভালো। এতে কলের সময় মৌলিক তথ্য পুনরায় জিজ্ঞেস না করে অগ্রাধিকার, কাজের পরিধি ও সিদ্ধান্ত নিয়ে কথা বলা যায়।

অনবোর্ডিং কলে কতগুলো প্রশ্ন করা উচিত?

নির্দিষ্ট কোনো সংখ্যা নেই। প্রকল্প শুরু করতে যে তথ্যগুলো সত্যিই দরকার, প্রশ্নগুলো সেগুলো ঘিরেই হওয়া উচিত। ছোট প্রকল্পে অল্প কয়েকটি প্রশ্নই যথেষ্ট হতে পারে, আবার একাধিক দল, প্রযুক্তিগত সংযোগ বা অনুমোদনের ধাপ থাকলে বেশি প্রশ্ন প্রয়োজন হতে পারে। প্রশ্নের সংখ্যার চেয়ে কোন উত্তর না পেলে কাজ আটকে যাবে, সেটি বেশি গুরুত্বপূর্ণ।

সিদ্ধান্তদাতা ব্যক্তি কলে উপস্থিত না থাকলে কী করবেন?

যে সিদ্ধান্তগুলো সঙ্গে সঙ্গে নেওয়া যাচ্ছে না, সেগুলো খোলা বিষয় হিসেবে লিখে রাখুন। পাশাপাশি ঠিক করুন কে সিদ্ধান্ত দেবেন এবং কবে উত্তর পাওয়া যাবে। প্রয়োজন হলে সংশ্লিষ্ট ব্যক্তিকে পরবর্তী বৈঠক বা নির্দিষ্ট অনুমোদনপর্বে যুক্ত করুন। “পরে জানাব” বলে বিষয়টি খোলা রেখে দিলে বাস্তবায়নের সময় অপ্রয়োজনীয় অপেক্ষা তৈরি হতে পারে।

অনবোর্ডিং কলের পরে কী লিখিতভাবে রাখা উচিত?

অন্তত নেওয়া সিদ্ধান্ত, বাকি প্রশ্ন, পরবর্তী কাজ, দায়িত্বপ্রাপ্ত ব্যক্তি, সময়সীমা, গুরুত্বপূর্ণ ধাপ এবং কাজ আটকে রাখা কোনো নির্ভরতা থাকলে সেটি লিখে রাখুন। পুরো কথোপকথনের প্রতিলিপির চেয়ে এমন সংক্ষিপ্ত নথি বেশি কার্যকর, যেখান থেকে সবাই দ্রুত বুঝতে পারে পরবর্তী কাজ কী।

কখন নিরাপত্তা বা গোপনীয়তা যাচাই নিয়ে কথা বলা দরকার?

গ্রাহকের তথ্য, অর্থপ্রদানের তথ্য, গোপন ব্যবসায়িক তথ্য বা সংবেদনশীল ব্যবস্থায় প্রবেশাধিকার জড়িত থাকলে শুরুতেই বিষয়টি তুলুন। প্রতিষ্ঠানের নিজস্ব নিরাপত্তা যাচাই, তথ্যপ্রযুক্তি বিভাগের অনুমোদন, নিরাপত্তা প্রশ্নমালা বা গোপনীয়তা পর্যালোচনা থাকতে পারে। সব প্রতিষ্ঠানের নিয়ম এক নয়, তাই অনুমান না করে সংশ্লিষ্ট নীতি আগেই জেনে নেওয়া ভালো।