புராஜக்ட் மேனேஜ்மெண்ட் 18 : மீட்டிங்

மீட்டிங் என்பது டேட்டிங் போல‌

மீட்டிங் என்பது டேட்டிங் போலவா ? என்னய்யா மொட்டைக்கும், முழங்காலுக்கும் முடிச்சு போடறீங்க என உங்கள் மனதில் ஒரு குரல் ஒலித்தால், அது ஒலிக்கட்டும். அது எவ்வளவு உண்மை என்பதை கொஞ்சம் நிதானமாக ஆராய்ந்து பார்த்தால் கண்டு கொள்வீர்கள். 

ஒரு டேட்டிங் போக வேண்டுமெனில் எவ்வளவு தயாராவீர்கள் ? எவ்வளவு தூரம் அதைப்பற்றிச் சிந்திப்பீர்கள் ? எவ்வளவு தூரம் அந்த பொழுதை பயனுள்ளதாக்க வேண்டுமென நினைப்பீர்கள் ? எப்படி கரெக்டாக அந்த நேரத்தில் சென்று சந்திப்பீர்கள், ஒவ்வொரு கணத்தையும் எப்படிச் செலவிட வேண்டும் என்பதை மனதுக்குள்ளேயே ஓட்டிப் பார்ப்பீர்கள், அந்த டேட்டிங் சக்சஸ் ஆக வேண்டும் என நினைப்பீர்கள்.. இப்படி சொல்லிக் கொண்டே போகலாம், இல்லையா ?

அதே நேரம் மீட்டிங் என்றால் எப்படி இருக்கிறது நமது மனநிலை. மீட்டிங் துவங்கும் போது மீட்டிங் ரூம் காற்று வாங்கிக் கொண்டு காத்துக் கிடக்கும். குறைந்த பட்சம் பத்து பதினைந்து நிமிடங்களாவது தாமதமாகத் தான் மீட்டிங் துவங்கும். வந்த பின்பும், “எதுக்குப்பா இந்த மீட்டிங் ?”  என்பதில் பாதி பேருக்கு குழப்பம் இருக்கும். சில வேளைகளில் மீட்டிங் அழைப்பு விடுத்தவருக்கே ஒரு தெளிவு இருக்காது. மீட்டிங் முடிந்த பின்பு, இது ஒரு வேஸ்ட் மீட்டிங் என்றோ, இந்த டைம்ல வேற ஏதாச்சும் செய்திருக்கலாம் என்றோ, மீட்டிங்கோட நோக்கம் முழுசா நிறைவேறலை என்றோ புலம்புவது வெகு சகஜம்.

ஒரு மீட்டிங் சரியாக நடத்தப்படவில்லையேல் அதன் முதல் பழி ஏற்க வேண்டியவர் புராஜக்ட் மேனேஜர் என்பதில் சந்தேகமே இல்லை. ஒரு மீட்டிங்கை நடத்துவதொன்றும் கத்தரிக்கா வாங்குவது போல எளிதான விஷயம் அல்ல. காரணம் ஒவ்வொரு மீட்டிங்கும் பல்வேறு நபர்களின் ஒருங்கிணைப்பில் தான் நடத்தப்பட வேண்டும் என்பதில் உள்ள சிக்கல். அதனால் தான் மீட்டிங் எப்படி நடக்க வேண்டும் என்பதற்கான சிறப்பான வழிமுறைகள் பல இருக்கின்றன. 

1. ஒரு மீட்டிங் ஏன் நடக்கிறது ? எதற்காக அந்த மீட்டிங் அழைப்பு விடுக்கப்படுகிறது என்பதில் தெளிவு வேண்டும். அப்போது தான் அந்த சந்திப்புக்கு யாரையெல்லாம் அழைக்க வேண்டும் என்பது தெரியவரும். மீட்டிங் துவங்கும் முன்பே அந்த மீட்டிங்கிற்கு வரவேண்டியவர்கள் எல்லோரும் வந்தார்களா என்பதையும் கவனித்து வருகைப் பதிவு செய்ய வேண்டும். 

2. யாரெல்லாம் மீட்டிங்கில் வரவேண்டும் என்பதை மிகக் கவனமாக யோசிக்க வேண்டும். எந்த விஷயத்தைப் பற்றி அந்த சந்திப்பு நடக்கிறதோ அந்த விஷயம் தான் கலந்து கொள்ள வேண்டிய‌ நபர்களை முடிவு செய்யும். முக்கியமான மூன்று வகையான நபர்கள் அழைக்கப்பட வேண்டும். ஒன்று, யாரிடமெல்லாம் அந்த தகவல் இருக்கிறதோ அந்த ஆட்கள். இரண்டு, யாருக்கெல்லாம் அந்த செய்தி சென்று சேரவேண்டுமோ அவர்கள். மூன்றாவது, யாரெல்லாம் இந்த விஷயத்தில் முடிவெடுக்கும் நிலையில் இருக்கிறாரோ அவர்கள். அவர்களுக்கெல்லாம் அழைப்பு விடுப்பதும், அவர்கள் மீட்டிங்கில் கலந்து கொள்வதை உறுதி செய்வதும் புராஜக்ட் மேனேஜரின் கடமையாகும்.

3. மீட்டிங் அழைப்பு விடுக்கும் போது சரியான கால அளவு கொடுப்பது மிக மிக முக்கியமான விஷயம். அதுவும் முக்கியமான நபர்கள் வரவேண்டியிருந்தாலும், நிறைய பேர் பங்கு பெற வேண்டியிருந்தாலும் போதுமான கால அவகாசம் கொடுக்க வேண்டும். அவசர நிலை தவிர வேறு எந்த விஷயத்துக்காகவும், திடீர் திடீரென மீட்டிங்கிற்கு அழைப்பு விடுக்கக் கூடாது. குறிப்பாக திட்டமிட்டு நடத்தப்படுகின்ற சந்திப்புக்களுக்கு எல்லோருக்கும் வசதியான ஒரு நேரத்தை பதிவு செய்ய வேண்டியது அவசியம்.

4. ஒருவேளை மீட்டிங்கில் கலந்து கொள்ள வேண்டிய நபர் பல நாடுகளிலும் இருந்தால், டைம் சோன் அதாவது அந்தந்த நாட்டின் நேரத்தையும் கணக்கில் கொள்ள வேண்டும். பணியாளர்களுடைய தனிப்பட்ட குடும்ப‌ நேரத்தைப் பாதிக்காத வகையில் அந்த மீட்டிங் நேரம் அமைய வேண்டும்.

5. அழைக்கப்பட்ட நபர்களுக்கு அந்த சந்திப்பின் காரணத்தையும், அந்த நபரிடமிருந்து என்ன எதிர்பார்க்கிறோம் என்பதையும் முன்கூட்டியே தெளிவாகச் சொல்லிவிட வேண்டும். அப்போது தான் மக்கள் தயாராய் வருவார்கள். குறைந்த பட்ச தயாரிப்பாவது இருப்பது எந்த ஒரு சந்திப்பையும் வெற்றிகரமாய் முடிக்க உதவும். 

6. நிகழ்ச்சி நிரல் உருவாக்கப் பட‌ வேண்டியது மிக முக்கியம். என்னென்ன விஷயங்கள் அலசப்படப் போகின்றன. யாரெல்லாம் எந்தெந்த விஷயங்கள் பேசப் போகிறோம். என்னென்ன முடிவுகள் எடுக்கப்பட வேண்டும் போன்றவையெல்லாம் நிகழ்ச்சி நிரலில் இருப்பது நல்லது. சரியான அஜென்டா இருந்தால் மீட்டிங் சரியான நேரத்தில் முடியவும் செய்யும், சரியான பாதையில் பயணிக்கவும் செய்யும். 

7.அஜென்டாவை புராஜக்ட் மேனேஜர் உருவாக்கியபின் அந்த மீட்டிங் அஜென்டாவில் எதையேனும் சேர்க்க வேண்டுமா என முக்கியமான நபர்களிடம் ஆலோசிக்க வேண்டியது அவரது கடமையாகும். மீட்டிங் துவங்கிய பின், “அதையும் பேசுவோமே, இதையும் பேசுவோமே, இதை மிஸ் பண்ணிட்டோமே” என புதிய ரூட் மாறாமல் இருப்பது ரொம்ப நல்லது.

8. முக்கியமான விஷயங்களில் ஒன்று, மீட்டிங் சரியான நேரத்தில் துவங்குவது. அதை விட முக்கியமான விஷயம் சரியான நேரத்தில் முடிவது. சாதாரண மீட்டிங் ஒரு அரை மணி நேரத்தில் முடிவது நல்லது. முக்கியமான மீட்டிங் எனில் ஒரு மணி நேரம் ! அதைத் தாண்டிய மீட்டிங் எல்லாம் தனது நோக்கத்தை நிறைவு செய்வதில்லை. அதனால் தான் இன்றைய தொழில்நுட்பம் “ஸ்டேன்ட் அப் மீட்டிங்” எனும் ஒரு சிந்தனையை அமுல்படுத்தியிருக்கிறது. இதன் படி, மீட்டிங் ஒரு பத்து அல்லது பதினைந்து நிமிடங்கள் தான் நடக்கும். யாரும் அமர முடியாது, நின்று கொண்டே தான் நடத்த வேண்டும். தினசரி ஸ்டேட்டஸ் அப்டேட்களுக்கு இந்த வகை மீட்டிங் ரொம்பவே கைகொடுக்கிறது. 

9. மீட்டிங் சரியான நேரத்தில் ஆரம்பிக்க வேண்டியது மிக முக்கியம். “ஒருத்தரு வந்துட்டிருக்காரு.. கொஞ்சம் வெயிட் பண்ணுங்க” , “ஒருத்தரு பஜ்ஜி சாப்பிட்டிருக்காரு.. ரெண்டு நிமிஷம்” என்றெல்லாம் வருகின்ற சாக்குப் போக்குகளை ஒதுக்கித் தள்ளி விட்டு மீட்டிங்கை ஆரம்பிக்க வேண்டியது புராஜக்ட் மேனேஜரின் கடமைகளில் ஒன்று.

10. மினிட்ஸ் ஆஃப் த மீட்டிங் எனப்படும், மீட்டிங்கில் நடக்கும் விஷயங்களை குறித்து வைக்க வேண்டியதும் புராஜக்ட் மேனேஜரின் முக்கியமான கடமை. அந்த பணிக்காக அவர் இன்னொரு நபரையும் நியமிக்கலாம். ஆனால் அது மிக முக்கியமான ஒரு அம்சம் என்பதை மட்டும் மறந்து விடக் கூடாது. அதில் முக்கியமாக என்னென்ன முடிவுகள் எடுக்கப்படுகின்றன போன்றவை தவற விடாமல் பதிவு செய்யப்பட வேண்டும். அதை மீட்டிங் முடிந்தபின் அழைக்கப்பட்ட அனைவருக்கும் அனுப்பவும் வேண்டும். மீட்டிங் நடந்த 24 மணி நேரத்துக்குள் அது அனுப்பப்பட வேண்டும் என்பது அடிப்படை விதி. 

இந்த பத்து விஷயங்களையும் மனதில் கொண்டால் ஒரு மீட்டிங் வெற்றிகரமாக அமையும். அதன்பின் அந்த மீட்டிங்கில் நடந்த விஷயங்களைப் பற்றி எல்லோருக்கும் அறிவிப்பதும், அதில் எடுக்கப்பட்ட முடிவுகள் சரியாக செயல்படுத்தப்படுகிறதா என்பதைக் கவனிப்பதும் புராஜக்ட் மேனேஜரின் வேலை. 

வழக்கமாக செய்ய வேண்டிய திட்டமிடப்பட்ட‌ மீட்டிங் களுக்கு ஒரு குறிப்பிட்ட நேரத்தை ஒதுக்குவது அதிக பயனளிக்கும். “டெய்லி காலைல 11 மணிக்கு மீட்டிங்” என்றோ, “செவ்வாய்க்கிழமை நம்ம மீட்டிங் இருக்கு” என்றோ ஊழியர்களுடைய மனதில் அது பதிந்து விடும். இதன் மூலம் மீட்டிங்கை மிஸ் பண்ணாமல் எல்லோரும் கலந்து கொள்ள வழிவகை செய்யும்.

எல்லா மீட்டிங் களும் திட்டமிட்டு நடத்தப்பட முடியாது. சில மீட்டிங்களை திடீர் திடீரென தான் நடத்த வேண்டியிருக்கும். புராஜக்ட்ல ஒரு பிரச்சினை உடனே அதை சரி செய்யணும் எனும் எமர்ஜென்சி வரும்போது திடீர் மீட்டிங்கள் அழைக்கப்பட வேண்டும். ஆனால், அந்த சூழலில் கூட கூடுமானவரை அந்த மீட்டிங்கை கட்டுக்கோப்பாய் நடத்திக் கொண்டு போக வேண்டியது புராஜக்ட் மேனேஜரின் பணியாகும்.

முதலிலேயே சொன்னது போல, மீட்டிங் என்பது ஒரு டேட்டிங் போல முக்கியமானதாகக் கருதி அனைத்தையும் திட்டமிட வேண்டும். திட்டமிட்டபடி மீட்டிங்கை நடத்தவேண்டும். அந்த மீட்டிங்கில் எடுக்கப்பட்ட முடிவுகள் செயல்படுத்தப்படும் வரை “ஃபாலோ அப்” செய்ய வேண்டும். 

*

சேவியர்

புராஜக்ட் மேனேஜ்மெண்ட் 16 : கம்யூனிகேஷன்

16. கம்யூனிகேஷன்

சைனீஸ் விஸ்பர் என்றொரு விளையாட்டு கேள்விப்பட்டிருக்கிறீர்களா ? பத்து பதினைந்து பேர் ஒரு வரிசையில் நிற்பார்கள். அல்லது ஒரு பெரிய வட்டமாக நிற்பார்கள். முதலில் நிற்பவரிடம் ஒரு துண்டுச் சீட்டு கொடுக்கப்படும். அதில் எழுதப்பட்டுள்ள வாக்கியத்தை அவர் வாசிக்க வேண்டும். பின்னர் துண்டைத் திருப்பிக் கொடுக்க வேண்டும். இப்போது வாசித்த நபர், தான் வாசித்த விஷயத்தை தனக்கு அருகில் நிற்பவருடைய காதில் மிக ரகசியமாகச் சொல்ல வேண்டும். வேறு யாருக்கும் கேட்கக் கூடாது.

அந்த நபர் அந்த செய்தியை அவருக்கு அடுத்திருக்கும் நபருக்குச் சொல்ல வேண்டும். அதைக் கேட்ட அந்த நபர் அடுத்த நபருக்குச் சொல்ல வேண்டும். இப்படி அந்த செய்தி ஒவ்வொரு காதாகத் தாண்டி, கடைசியாய் நிற்கும் நபரிடம் சென்று சேரும். அப்படி சென்று சேர்ந்த செய்தி என்ன என்பதை அவர் கடைசியில் உரக்கச் சொல்ல வேண்டும். இப்போது எழுதப்பட்டிருக்கும் வாசகம் என்ன என்பதை வாசித்துக் காட்டுவார்கள். 

சின்ன விளையாட்டு தானே என தோன்றும். ஆனால், இந்த விளையாட்டின் முடிவு மிகவும் வியப்பானதாக இருக்கும். முதலில் பேப்பரில் எழுதப்பட்டிருந்த‌ செய்திக்கும், கடைசியில் சென்று சேரும் செய்திக்கும் மலைக்கும் மடுவுக்குமான வேறுபாடுகள் உண்டாகியிருக்கும். கம்யூனிகேஷனின் பிரச்சினைகளைப் பற்றிப் பேசும் போது இந்தக் கதையை உதாரணமாகச் சொல்வார்கள். 

ஒரு புராஜக்ட் மேனேஜரிடம் இருக்க வேண்டிய மிக முக்கியமான குணாதியம் கம்யூனிகேஷன். சரியான நேரத்தில், சரியான செய்தியை, சரியான குழுவுக்குப் பகிர்வது இந்த‌ கம்யூனிகேஷனின் அடிப்படை. “ஓவர் கம்யூனிகேஷன் ஈஸ் பெட்டர் தேன் நோ கம்யூனிகேஷன்” என ஆங்கிலத்தில் ஒரு சொலவடை உண்டு. அதாவது, “தகவல்களைப் பகிராமல் இருப்பதை விட, அளவுக்கு அதிகமாகவே தகவல்களைப் பகிர்வது நல்லது” என்பது தான் அது.

புராஜக்ட் என்றல்ல‌. எந்த ஒரு விஷயத்தை எடுத்துக் கொண்டாலும் சரியான கம்யூனிகேஷன் தான் வெற்றிகளைக் கொண்டு வரும். வாழ்க்கையானாலும் சரி, உறவுகளானாலும் சரி, புராஜக்ட் ஆனாலும் சரி வெளிப்படையான நேர்மையான சரியான தகவல் பரிமாற்றங்களே வெற்றிக்கு அடிப்படை. 

புராஜக்டில் ஈடுபட்டுள்ள பணியாளர்கள், அவர்களை வழிநடத்துபவர்கள், ஏதோ ஒரு வகையில் புராஜக்டோடு  தொடர்புடையவர்கள் அனைவரும் புராஜக்ட் எந்த நிலமையில் இருக்கிறது என்பதைப் புரிந்து கொள்ளவும். “எனக்கு இது தெரியாதே !” என கடைசி நிமிட கலாட்டாக்கள் உருவாகாமல் இருக்கவும் இந்த கம்யூனிகேஷன் ரொம்ப முக்கியம்.

ஏதாவது ஒரு பிரச்சினை எழுந்தால் அதற்கான தீர்வைப் பெற்றுக் கொள்ள இந்த நிலையான தகவல் தொடர்பு பயன்படும். பல வேளைகளில் பிரச்சினைகள் உருவாகாமல் இந்த கம்யூனிகேஷன் நம்மைக் காப்பாற்றவும் செய்யும். “என்கிட்டே சொல்லியிருந்தா, இந்த பிரச்சினையை ஈசியா முடிச்சிருப்பேன்” என சொல்வதைக் கேட்டிருப்பீர்கள் இல்லையா ? அந்த சிக்கல்கள் வராமல் இது காப்பாற்றும்.

புராஜக்ட் எந்த எல்லையை நோக்கிச் சென்று கொண்டிருக்கிறது எனும் தெளிவான ரூட் அனைவருக்கும் தெரிய வரும். கொஞ்சம் பாதை மாறினால் கூட, ” இது சரியில்லை, இதை இப்படி பண்ணணும்” என ஆலோசனைகளைப் பெற்றுக் கொள்ள தொடர்ந்த‌ கம்யூனிகேஷன் வழி வகை செய்யும். 

புராஜக்ட் ஒவ்வொரு மைல் கல்லை அடையும் போதும், உற்சாகமடையவும், ஊக்கமடையவும் இத்தகைய தொடர்பு பயனளிக்கும். “பரவாயில்லை, இவ்ளோ வந்துட்டோம் எனும் ஒரு தன்னம்பிக்கையை இது உருவாக்கும் “

புராஜக்ட்சில் உள்ளவர்களும், அதோடு தொடர்புடையவர்களும் ஒரு நல்ல புரிதலோடு செயலாற்ற இந்த தொடர்பாடல் உதவும். 

கம்யூனிகேஷன் ஒரு சின்ன மேட்டர் என பலரும் நினைப்பதுண்டு. எப்படி ஒரு மாட்டு வண்டிக்கு ஒரு சிறிய அச்சாணி முக்கியமானதாக இருக்கிறதோ அதே போல தான் இந்த கம்யூனிகேஷனும். இதை உதாசீனப்படுத்தினால் நிச்சயம் பல எதிர்பாராத சவால்கள் புராஜக்ட்டில் வந்து விழும் என்பதில் சந்தேகமில்லை. 

கம்யூனிகேஷனை மிகச் சரியாகச் செயல்படுத்தும் நிறுவனங்களும், புராஜக்ட்களும் வெற்றிகளைக் குவிக்கும். நாம் சொல்ல வருகின்ற செய்தி சிதையாமல், பெற்றுக் கொள்ளும் நபரை அடைய வேண்டும் என்பதே கம்யூனிகேஷனின் அடிப்படைத் தத்துவம். 

இதில் ஐந்து முக்கியமான அம்சங்கள் உண்டு.

1. சொல்ல வேண்டிய செய்தி என்ன ?

2. அதைச் சொல்லப் போகிறவர் யார்

3. யாருக்காக அதைச் சொல்லப் போகிறார் ? 

4. எப்படி அதை சொல்லப் போகிறார் ? எழுத்து, குரல், ஓவியம், செய்கை இப்படி ஏதோ ஒன்று. 

5. எதன் வழியாக ( மீடியம் ) அதைச் சொல்லப் போகிறார் ? 

எந்த ஒரு தகவல் பரிமாற்றத்தின் போதும் இந்த அம்சங்களை மனதில் கொள்ள வேண்டும். இதன் மாறுதல்களுக்கு ஏற்ப கம்யூனிகேஷனில் மாற்றம் இருக்கும்.

இந்த தகவல் பரிமாற்றத்தில் இரண்டு வகை உண்டு. 

1. ஒரு வழிச் செய்திப் பரிமாற்றம். ஒன்வே கம்யூனிகேஷன். இதில் ஒரு நபர் ஒரு செய்தியைச் சொல்வார். அடுத்த நபர் அதைக் கேட்டு புரிந்து கொள்வார் அவ்வளவு தான். உதாரணமாக கம்பெனியின் தலைவர் ஊழியர்களுக்கு ஒரு சுற்று மடல் அனுப்புகிறார் என வைத்துக் கொள்ளுங்கள். அது ஒரு வழிச் செய்தி. அதில் நாம் எதையும் திரும்ப சொல்ல தேவையில்லை. அல்லது ஒரு இணைய தளத்திலிருந்து ஒரு தகவலை தரவிறக்கம் செய்கிறீர்கள். அது ஒன்வே கம்யூனிகேஷன்.

2. இரு வழிப் பாதை. இது ஒருவர் பேசுவதை இன்னொருவர் கேட்பதும். அதற்கு அவர் பதில் சொல்வதுமாக இருக்கும். நேரடியாகப் பேசும் உரையாடல்கள், தொலைபேசி மூலம் பேசும் உரையாடல்கள் போன்றவையெல்லாம் இரு வழிப் பாதையின் உதாரணங்கள். குரல் மூலமாகவோ, உடல் மொழியின் மூலமாகவோ நாம் இங்கெல்லாம் தகவலைப் பரிமாற்றம் செய்ய முடியும். இருவழிக் கம்யூனிகேஷன் தான் மிக முக்கியமானதும், வலிமையானதும் என்பதைத் தனியே சொல்லத் தேவையில்லை. 

கம்யூனிகேஷன் என்றதும் பேசுவது என்று தான் நாம் எல்லோரும் நினைக்கிறோம். பேசுவதைப் போலவே மிக முக்கியமான அம்சம் “கவனித்தல்/கேட்டல்” என்பதாகும். பேசுவதும், கேட்பதும், புரிந்து கொள்வதும் இணையும் போது தான் ஒரு தகவல் பரிமாற்றம் நேர்த்தியாகத் தன் பணியைச் செய்து முடித்தது என சொல்ல முடியும். 

சொல்வதை அப்படியே புரிந்து கொள்ளும் வகையில் கேட்பதை, “ஆக்டிவ் லிசனிங்” என்பார்கள். “நான் என்ன சொன்னேன், நீ என்ன செஞ்சிருக்கே” போன்றவையெல்லாம் தகவல் பரிமாற்றத் தோல்வியின் வாசகங்கள். 

மனித மூளை எல்லா செய்திகளையும் காட்சிகளாகச் சேமிக்கும் என்கின்றனர் வல்லுநர்கள். நாம் வார்த்தைகளாய்ச் சொல்லும் விஷயங்கள் கூட படங்களாக இருந்தால் மிக எளிதாக மூளையில் பற்றிக் கொள்ளும். அதனால் தான் கம்யூனிகேஷனில் காட்சிப் படுத்துதலை முக்கியமான ஒரு அம்சமாகச் சொல்வார்கள். சொல்லப்படுகின்ற வார்த்தையை ஒரு காட்சி போலவோ, ஒரு ஓவியம் போலவோ மனதில் தீட்டிக் கொள்வது இதில் ஒரு வகை.

பெற்றுக் கொண்ட செய்தியை மீண்டும் ஒரு முறை சொல்லி ஊர்ஜிதப்படுத்திக் கொள்வது தகவல் பரிமாற்றத்தில் ஏற்றுக் கொள்ளப்பட்ட ஒரு வழிமுறை. வடிவேலு நகைச்சுவை ஒன்று உண்டு. பத்து நிமிடம் பக்குவமாய் எப்படிப்பட்ட தோசை வேண்டுமென வடிவேலு விளக்குவார். சர்வரோ கடைசியில், “அண்ணனுக்கு ஒரு ஊத்தப்பம்” என முடிப்பார். வடிவேலு அதிர்ச்சியுடன் பார்ப்பார். சொல்ல வேண்டிய செய்தியைத் தெளிவாகச் சொல்லியாச்சு, ஆனால் கேட்க வேண்டியவர் உள்வாங்கிக் கொள்ளவில்லை. இது கம்யூனிகேஷன் தோல்வியே.

ஒரு செய்தியைப் பெற்றுக் கொள்ளும் போது, சந்தேகங்களையும், அனுமானங்களையும் தெளிவுபடுத்திக் கொள்வது மிகவும் அவசியம். அது தான் செய்தியின் முழுமைக்கு உதவும். 

இந்த தகவல் தொடர்பிலும் “முறையான தகவல் தொடர்பு”, “முறைகளைப் பின்பற்றாத தகவல் தொடர்பு” என இரண்டு வகையைச் சொல்லலாம். ஃபார்மல் அன்ட் இன்ஃபார்மல் கம்யூனிகேஷன். “அஸ் ஐ ஏம் சஃபரிங் ஃப்ரம் ஃபீவர்” என நாம் சின்ன வயதில் எழுதுகின்ற லீவ் லெட்டர்களை முறையான தகவல் தொடர்பின் உதாரணமய்க் கொள்ளலாம். அது ஒரு குறிப்பிட்ட கட்டமைப்புக்குள் இருக்கும். அதன் வடிவம் மாறாது. 

மற்றது வெகு இயல்பாக நடக்கும் தகவல் பரிமாற்றம். கடிதம் எழுதிக் கொடுத்த அதே ஆசிரியரை கடை வீதியில் சந்தித்தால், “நல்லாயிருக்கீங்களா சார்” என அழைத்து நாம் நிகழ்த்தும் குட்டி உரையாடல் இந்த வகையில் வரும். அலுவலகத்திலும் முறையான மின்னஞ்சல், கடிதப் பரிமாற்றமாக இல்லாமல் சாதாரணமாக நிகழும் உரையாடல்கள் இந்த வகையில் வரும்.

கம்யூனிகேஷனைப் பற்றி இன்னும் சற்று விரிவாக அடுத்த வாரம் பார்ப்போம்

*

சேவியர்

புராஜக்ட் மேனேஜ்மெண்ட் – 15 – மீண்டும்….

15

ரீ பேஸ்லைன் என்றால் என்ன

புராஜக்ட் மேனேஜ்மென்டில் அதிகம் கேட்கின்ற வார்த்தை “பேஸ்லைன்” என்பது. அதாவது ஒரு புராஜக்டின் மைல் கற்களைக் குறிப்பிடும் மதிப்பு தான் அது. அது புராஜக்டின் டெலிவரி நாளாக இருக்கலாம், அல்லது ஒரு சோதனையில் கிடைக்க வேண்டுமென தீர்மானித்திருக்கின்ற மதிப்பாகவும் சரி. முதலில் திட்டமிட்டு வைக்கின்ற மதிப்பு தான் பேஸ்லைன் என்பது.

உதாரணமாக, இந்த மாதம் 1000 கார்களை உற்பத்தி செய்யவேண்டும் என திட்டமிட்டிருந்தால் அதை பேஸ்லைன் 1000 என்பார்கள். ஒருவேளை அடுத்த மாதம் 15ம் தியதிக்கு முன்பு ஒரு பொருளைத் தயாரித்து முடிக்க வேண்டும் என திட்டமிட்டிருந்தால் அதை பேஸ்லைன் அடுத்த மாதம் பதினைந்தாம் தியதி என்பார்கள். 

சரி, ரீ பேஸ்லைன் என்றால் என்ன ? மீண்டும் ஒரு முறை அந்த பேஸ்லைன் மதிப்புகளை ஆராய்ந்து, புதிதாக ஒரு மதிப்பை வைப்பது தான் ரீ பேஸ்லைன். அது ஏன் புதிதாக ஒரு எல்லையை வரையறுக்க வேண்டும் ? அது பெரும்பாலும் ஒரு புராஜக்ட் எதிர்பார்த்த திசையில், எதிர்பார்த்த வேகத்தில் போகாமல் இருக்கும்போது மாற்றுவது. 

உதாரணமாக ஆறு மாத காலத்தில் ஒரு வீடு கட்டி முடிக்க வேண்டும் என திட்டமிடப்பட்டது என வைத்துக் கொள்ளுங்கள். முதல் மாதத்தில் அஸ்திவாரம், அடுத்த மாதம் கட்டுமானம், அதற்கடுத்தமாதம் காங்கிரீட் என மைல் கற்கள் இருக்கும். ஒருவேளை நான்காம் மாதத்தில் தான் அஸ்திவாரம் முடிந்தது என வைத்துக் கொள்ளுங்கள். ஆறு மாதத்தில் வீடு கட்டி முடிப்பது இயலாத காரியமாகிவிடும். அப்போது சரி, ” வீடு கட்டி முடிக்கும் நாளை, இன்னும் ஒரு நாலு மாசம் தள்ளி வைப்போம்” என்பார்கள். அந்த புதிய நாள் தான் ‘ரீ பேஸ்லைன் டேட்’. ஏன் நாள் தள்ளி வைக்கப்பட்டது என்பதன் காரணத்தையும் கூடவே பதிவு செய்து வைக்க வேண்டும். ஒருவேளை அஸ்திவாரம் போட முடியாதபடி பெரு மழை பெய்து கொண்டிருக்கலாம், அல்லது பணியாளர்கள் கிடைக்காமல் இருந்திருக்கலாம், இப்படி ஏதோ ஒரு காரணம் இருக்கும். இவையெல்லாம் ரீபேஸ்லைனுக்கான காரணங்களாய் பதிவு செய்ய வேண்டும். 

ரீபேஸ்லைன் என்பதை ஒரு புராஜக்ட் மேனேஜர் தான் விரும்பும் நேரத்தில், தனது இஷ்டப்படி செய்ய முடியாது. அதற்கு சில வரைமுறைகள் உண்டு. முதலில் அந்த புராஜக்ட் சம்பந்தப்பட்ட முக்கியமான நபர்களை எல்லாம் அழைத்து, புதிய நாள் என்னவாக இருக்கும் ? ஏன் பழைய நாளை மாற்ற வேண்டிய தேவை வந்தது போன்றவற்றையெல்லாம் விளக்க வேண்டும். அவர்களுடைய ஒப்புதல் மிக முக்கியம். அதே போல, புதிய பேஸ் லைன் உருவாக்கியதும், புராஜக்டிலுள்ள அத்தனை நபர்களுக்கும் அதைத் தெரியப்படுத்தவும் வேண்டும். 

பழைய பேஸ்லைன், அதன் திட்டங்கள் அதில் செய்த மாற்றங்கள் போன்ற அனைத்தையும் குறித்து வைத்துக்கொள்ள வேண்டியது அவசியம். புராஜக்ட் முடியும் போது அது கடந்து வந்த வரலாற்றைப் பதிவு செய்து வைக்க வேண்டியதும், அதிலிருந்து பாடம் கற்க வேண்டியதும் அவசியம். குறிப்பாக ‘ரெட்ரோஸ்பெக்டிவ்” எனப்படும் புராஜக்ட்டுக்குப் பிந்தைய அலசலுக்கு இந்த தகவல்களெல்லாம் மிக முக்கியம். 

ஒரு திட்டம் இடப்பட்டால் அது மாற்றத்துக்கு உட்படாது என சொல்ல முடியாது. ஒரு பொருளைச் சந்தைப்படுத்த தாமதம் ஏற்பட்டால் ரீ பேஸ்லைன் தேவைப்படும். கஸ்டமருடைய தேவை மாறலாம். ‘இனிமே இப்படி வேண்டாம், அப்படி பண்ணு’ என கஸ்டமர் புதிய தேவையை வெளிப்படுத்தலாம். சட்டென ஒரு புதிய தொழில்நுட்பம் வந்து பழைய திட்டத்தை அழிக்கலாம். அப்படிப்பட்ட சூழல்களிலெல்லாம் பேஸ்லைன் நாட்களை மாற்றி புதிய ரீ..பேஸ்லைன் செய்ய வேண்டிய தேவை வரும். 

ஒரு புராஜக்டில் ரீபேஸ்லைன் செய்ய வேண்டிய தேவை வருவது புராஜக்ட் சரியாகச் செல்லவில்லை என்பதன் அடையாளம். சில வேளைகளில் சூழலுக்கு ஏற்ப புராஜக்டில் செய்யப்பட வேண்டிய மாற்றங்கள் புராஜக்டை ரீபேஸ்லைன் செய்ய வைக்கும். எனவே எந்த புதிய வேலை வந்தாலும் உடனே சட்டென ஒத்துக் கொள்ளக் கூடாது, அதை அலசி ஆராய வேண்டும். 

1. புராஜக்டில் ஒரு மாற்றம் செய்ய வேண்டியிருந்தால், ‘அது என்ன மாற்றம்’ என்பதை முழுமையாகக் கேட்டுத் தெரிந்து கொள்ள வேண்டும். அந்த மாற்றம் குறித்த தெளிவான ஒப்புதல் எல்லோரிடமிருந்தும் பெறப்பட வேண்டும். அந்த மாற்றத்தைச் செய்ய வேண்டுமா, வேண்டாமா எனும் முடிவை எடுக்க வேண்டும். அப்படி முடிவை எடுக்கும் போது சம்பந்தப்பட்ட அனைத்து அதிகாரிகளிடமும் கலந்தாலோசிக்க வேண்டியது அவசியம். 

2. அந்த புதிய விஷயம் புராஜட்டில் கொண்டு வரப்போகும் மாற்றங்கள் என்னென்ன என்பதை மிகத் தெளிவாகப் புரிந்து கொள்ள வேண்டும். அதை இம்பேக்ட் அனாலிசிஸ் என்பார்கள். ஒருவேளை அந்த மாற்றத்தை செய்ய வேண்டாமென முடிவெடுத்தால், என்ன பாதிப்புகள் புராஜக்டுக்கு உருவாகும் என்பதையும் புரிந்து கொள்ள வேண்டும். ஒரு புராஜக்ட் மேனேஜரின் தேவை இந்த இடத்தில் மிக முக்கியம். 

3. அந்த மாற்றத்தை எப்படிச் செயல்படுத்தப் போகிறோம் என்பதை மிகத் தெளிவாக இம்ப்ளிமென்டேஷன் பிளான் என எழுதி வைக்க வேண்டும். அந்த மாற்றம் கொண்டு வரக் கூடிய ஷெட்யூல் மாற்றம்,  பட்ஜெட் மாற்றம் போன்ற அனைத்தையும் குறித்து வைக்க வேண்டும். அதை புராஜக்டோடு சம்பந்தப்பட்டவர்களிடம் தெரிவிக்கவும் வேண்டும்.  

மாற்றங்கள் தவிர்க்க முடியாதவை. ஆனால் “எப்படின்னாலும் மாற்றம் வரும்” எனும் சிந்தனையில் ஒரு திட்டத்தை உருவாக்கவே கூடாது. “இப்போதைக்கு இப்படியே போகட்டும், கடைசில எப்படியும் மாற்றம் வரும் அப்போ பாத்துக்கலாம்” எனும் அடிப்படையில் உருவாக்கப்படும் திட்டவரைவுகள் சிறப்பானவை அல்ல. ஒரு புராஜக்ட் மேனேஜரின் தோல்வி அது என சொல்லலாம். மாறாக, ஒரு திட்டத்தை உருவாக்கும் போது அதில் பிற்காலத்தில் எந்த மாற்றமும் செய்யத் தேவையில்லை எனுமளவுக்கு ஒவ்வொரு விஷயத்தையும் மிக நுணுக்கமாகக் கவனித்துச் செய்ய வேண்டும். 

சிறந்த ஹாலிவுட் இயக்குனர்கள் ஒரு திரைப்படத்தை உருவாக்குவதற்கு முன் அந்தப் படத்தின் கதையை முழுமையாக எழுதுவார்கள். அதன்பின் அந்தப் படத்தின் காட்சிகளை கண்முண் கொண்டுவரும் விதத்தில் ஒவ்வொரு காட்சியையும் கார்ட்டூனாக வரைவார்கள். அதற்கே பல ஆண்டுகள் ஆவதுண்டு. அந்த கார்ட்டூன் படத்தில் எங்கிருந்து வெளிச்சம் வரவேண்டும், என்னென்ன பொருட்கள் காட்சியில் இருக்கவேண்டும், நடிகர்கள் எந்த இடத்தில் இருக்கவேண்டும் என அத்தனை விஷயங்களையும் வரைவார்கள். அதன்பின் அவர்கள் படப்பிடிப்புக்குச் செல்லும்போது அந்த கார்ட்டூன் படத்தில் உள்ளதை நிஜத்தில் எடுக்க வேண்டும் அவ்வளவு தான். 

இந்த முறையில் படப்பிடிப்பு காலத்தில் கதையையோ, காட்சிகளையோ யோசித்து குழம்ப வேண்டிய தேவையில்லை. கடைசி கட்ட மாறுதல்கள் பணத்தையும், நேரத்தையும் வீணாக்குவதையும் தடுக்கலாம். அதை விட்டு விட்டு, ஒரு காட்சியை மேலோட்டமாக மனதில் நினைத்துவிட்டு செட்ல போய் பாத்துக்கலாம், என நினைத்தால் அது பல மாற்றங்களைக் கொண்டு வந்து, கடைசியில் புராஜக்டே தோல்வியில் முடியவும் வாய்ப்பு உண்டு. எனவே திட்டமிடலும், அதை மிக நேர்த்தியாக முதலிலேயே அலசி ஆராய்வதும் மிக மிக முக்கிய அம்சங்கள்

ஒரு திட்டத்தை உருவாக்கியபின்பு புராஜக்ட் செய்து கொண்டிருக்கும் காலத்தில் புதிது புதிதாக மாற்றங்கள் வருவது, முதலில் போட்ட திட்டத்தை வலுவிழக்கச் செய்யும். ஒரு புராஜக்டில் என்னென்ன இருக்க வேண்டும் எனும் பட்டியலை “ஸ்கோப்” என்பார்கள். அந்த ஸ்கோப்பின் அடிப்படையில் தான் திட்டங்கள் அமையும். அதில் வருகின்ற மாற்றங்களை, “ஸ்கோப் கிரீப்” என்பார்கள். முதலில் சொன்ன விஷயங்கள் இல்லாமல் மீண்டும் சிலவற்றைச் சேர்ப்பது தான் அது. 

ஒரு கதையைச் சொல்லி படம் எடுக்க ஆரம்பித்த பிறகு, தயாரிப்பாளர் கடைசியில் வந்து, “இந்த இடத்துல ஒரு பாட்டு போட்டுருப்பா” என சொன்னால் அது ஸ்கோப் கிரீப். காரணம், அந்த படத்துக்கான ஷெட்யூல், செலவு, கால அளவு, எதிலும் அது சேர்க்கப்பட்டிருக்கவில்லை. ஆனால் இப்போது அது தேவையாகிறது. இப்போது ஸ்கோப் & ஸ்கோப் கிரீப் பற்றி உங்களுக்குப் புரிந்திருக்கும் என நினைக்கிறேன். அதைப் பற்றி இங்கே சொல்லக் காரணம், “எந்த ஒரு ஸ்கோப் கிரீப்பும், பேஸ்லைனை ஆட்டம் காண வைத்து, ரீ பேஸ்லைன் செய்ய வைக்கும்” என்பது தான். ஒரு புதிய மாறுதல் வந்தும், பிளானில் எந்த மாற்றமும் வராத சூழல் மிகவும் அபூர்வம். 

*

சேவியர்

புராஜக்ட் மேனேஜ்மெண்ட் 14 – கவனித்தல்

14

கவனித்தல்

பிள்ளைகளை ஒரு நல்ல ஸ்கூல்ல சேர்க்க வேண்டும் என்பது எல்லா பெற்றோரிடமும் இருக்கக் கூடிய ஒரு பதட்டம் கலந்த எதிர்பார்ப்பு. அதற்காக பல ஸ்கூல் வாசல்களில் ஏறி இறங்கி விண்ணப்பப் படிவம் வாங்குவார்கள். அதன் பின் அதை நிரப்பி ஸ்கூல்களில் கொடுத்து, நேர்முகத் தேர்வுகளில் கலந்து கொண்டு, பிரார்த்தனைகள் செய்து, மிகப்பெரிய பணத்தையும் வாரி இறைத்து நல்ல ஒரு இடத்தில் அட்மிஷன் வாங்குவார்கள். அதன் பின்பு பெரும்பாலான பெற்றோர்கள், இனியெல்லாம் பள்ளிக்கூடம் பார்த்துக் கொள்ளும் என ஹாயாக அமர்ந்து விடுவார்கள். 

பெற்றோர் தொடர்ந்து கவனிக்காமல் இருக்கும் போது பிள்ளைகளின் படிப்பு நாளுக்கு நாள் பலவீனமாகிக் கொண்டே இருக்க வாய்ப்பு அதிகம். அப்புறம் மார்க் வரும்போ தான் தெரியும் பிள்ளை நினைத்த அளவுக்கு படிப்பில் சுட்டியாக இல்லை என்பது. அப்படிப்பட்ட ஒரு சூழல் வராமலிருக்க என்ன செய்ய வேண்டும் ?  ஒவ்வொரு நாளும் குழந்தை என்ன படிக்கிறது, எப்படி படிக்கிறது ? படிப்பதற்கு வேண்டிய சூழல் இருக்கிறதா ? ஏதேனும் தேவைகள் இருக்கிறதா ? குழந்தைக்கு ஏதேனும் மன வருத்தங்கள் இருக்கிறதா ? என ஒவ்வொரு விஷயத்தையும் தொடர்ந்து கவனிப்பதும், அதற்கேற்க செயல்படுவதும் தான். 

புராஜக்ட் விஷயத்திலும் அப்படித் தான். ஆட்களை நியமித்தாயிற்று வேலை தொடங்கியாயிற்று என ஹாயாக ஓய்வெடுத்தால் புராஜக்ட் நினைத்த வேகத்தில் நகராது. ஆமை போல நடக்கத் தொடங்கும். சில வேளைகளில் தவறான திசையில் பயணிக்கவும் செய்யும். எனவே தான் இந்த ‘மானிட்டரிங் & கன்ட்ரோல்’ எனப்படும் தொடர்ந்து கவனிப்பதும், கட்டுப்பாட்டில் வைத்திருப்பதும் மிகவும் முக்கியமான அம்சமாகிறது.

முதலில் புராஜக்ட் துவங்கும் முன்பாகவே புராஜக்டில் பணி செய்யப் போகின்ற அத்தனை நபர்களையும் சந்தித்து அவர்களிடம் வேலையைப் பற்றிய சரியான புரிதல் இருக்கிறதா என்பதை ஊர்ஜிதப்படுத்திக் கொள்ள வேண்டும்.

என்ன செய்ய வேண்டும்  ?

எத்தனை நாட்களில் முடிக்க வேண்டும் ?

எவ்வளவு உழைப்பு தேவைப்படும் ?

போன்ற விஷயங்களெல்லாம் பணியாளர்களுக்கு மிகத் தெளிவாகத் தெரிந்திருக வேண்டும். அதில் ஏதேனும் சந்தேகங்கள் இருக்கிறதா என்பதைக் கேட்டுத் தெரிந்து கொண்டு, தெளிவை உருவாக்குவது கொள்வது முதல் நிலை. 

அதன் பின் ஒரு குறிப்பிட்ட மைல் கல்லை எட்டியபிறகு பணியாளர்கள் எப்படிப் பணி செய்திருக்கிறார்கள் என்பதைக் குறித்த ஒரு அலசல் மிக முக்கியம். அதிலும் குறிப்பாக, நீண்ட கால புராஜக்ட்களுக்கு இத்தகைய பரிசோதனை மிகவும் தேவை. 

கொடுக்கப்பட்டுள்ள பணிகளை முடித்திருக்கிறார்களா ?

எந்த நாளில் அந்த வேலை முடிக்கப்பட்டது ? யார் முடித்தது ? அந்த நாளுக்கும் திட்டமிட்ட நாளுக்கும் இடையேயுள்ள வித்தியாசம் என்ன ?

இடைப்பட்ட மைல் கற்களை எந்தெந்த தேதிகளில் எட்டினார்கள் ? 

ஒவ்வொரு பணிக்கும் எவ்வளவு நாட்கள் எடுத்துக் கொண்டார்கள் ?

எவ்வளவு செலவு செய்யப்பட்டது ?

எவ்வளவு உதவிகள் தேவைப்பட்டன ?

வேலை முடிக்கும் வரை அந்த பணியாளர் வேலையையும், அவருடைய அதிகாரிகளையும் எதிர்கொண்ட விதம் எப்படி இருந்தது ?

இப்படிப்பட்ட தகவல்களை கவனமாகச் சேமித்து, அந்த நபருக்குரிய அடுத்த கட்ட பணிகளைக் கொடுக்கலாம். அவருக்கு போனஸ், அங்கீகாரம் போன்றவற்றைக் கொடுப்பது பற்றிய முடிவையும் எடுக்கலாம். இத்தகைய தகவல்கள் ஹிஸ்டாரிக் டேட்டாவாக அடுத்து வருகின்ற புராஜக்ட்களுக்குக் கைகொடுக்கும். 

ஒருவேளை எதிர்பார்த்த அளவுக்கு ஒரு நபர் பணி செய்யவில்லையெனில் அதை சரிபடுத்தும் முயற்சிகளிலும் ஈடுபட நேரம் கிடைக்கும். குறிப்பாக ஒவ்வொரு மைல்கல்லுக்கும் இடையே அந்த நபருடைய செயல்பாட்டைக் கவனித்து வந்தால், சரியான ஆலோசனையும், பயிற்சியும் அந்தந்த நேரங்களில் கொடுக்க முடியும். 

பொதுவாக நம்முடைய புராஜக்ட் எவ்வளவு பெரியது என்பதை மனதில் வைத்து இந்த ரிவ்யூ காலத்தை நிர்ணயிக்கலாம். சில வேலைகள் அதிக ரிஸ்க் இல்லாததாய் இருக்கும், அங்கே அடிக்கடி கவனிக்கத் தேவையில்லை. சில இடங்கள் ரிஸ்க் அதிகமானதாக இருக்கும் அந்த இடங்களில் அதிக கவனிப்பை நாம் செலுத்த வேண்டும். 

நமக்கு தெரிஞ்ச டீம் தானே, நமக்குத் தெரிஞ்ச மக்கள் தானே, இதுக்கு முன்னாடியும் இப்படிப்பட்ட புராஜக்ட் செஞ்சிருக்காங்களே, இவங்க கிட்டே போய் மறுபடியும் மறுபடியும் பேசணுமா ? என ஒரு புராஜக்ட் மேனேஜர் நினைக்கவே கூடாது. எப்படி டிராபிக்கை நெறிப்படுத்தவும், கண்காணிக்கவும், கட்டுப்படுத்தவும் ஒரு டிராபிக் காவலர் தேவையோ அப்படியே ஒரு புராஜக்டை கட்டுக்குள் வைத்துக் கவனிக்க ஒரு புராஜக்ட் மேனேஜர் ரொம்ப அவசியம். இது அவர்கள் மீதான நம்பிக்கையின்மையின் வெளிப்பாடல்ல, கொடுக்கப்பட்டிருக்கும் பணி சிறப்பாகச் செயல்பட அவசியமான ஒரு அணுகுமுறை என்பதை எல்லோரும் புரிந்து கொள்ள வேண்டும்.

பணிகளை மேனேஜர் கவனிப்பதும், ஆலோசனை கூறுவதும் குழுவிலுள்ளவர்களுக்கு உற்சாகம் ஊட்டுவதாக இருக்கவேண்டுமே தவிர எரிச்சல் மூட்டுவதாய் இருக்கக் கூடாது என்பது பாலபாடம். அதனால் தான் புராஜக்ட் மேனேஜர்களுக்கு “இன்டர் பர்சனல் ஸ்கில்ஸ்” மிக மிக முக்கியம் என்கின்றனர் வல்லுநர்கள். 

ஒரு புராஜக்ட் எப்படி போயிட்டிருக்கு என்பதை அறிந்து கொள்ள நிறைய வழிகள் உண்டு. நிறைய மென்பொருட்கள் இதற்காகப் பயன்படுத்தப்படுகின்றன. பொதுவாக அவற்றை “மேஜேன்மென்ட் இன்ஃபர்மேஷன் சிஸ்டம்” என்பார்கள். நாம் கொடுக்கின்ற தகவல்களைப் பெற்று, நமது இலக்குகளோடு  ஒப்பிட்டு, ஒரு ரிப்போர்ட்டை தருவது தான் இத்தகைய மென்பொருட்களின் முதன்மை வேலை. பல நிறுவனங்கள் இத்தகைய மென்பொருட்களை உருவாக்கியிருக்கின்றன. புராஜக்டின் தேவைக்கு ஏற்ப இலவச மென்பொருட்களையோ (ஃப்ரீவேர் ), பணம் கொடுத்துப் பெற்றுக் கொள்ள வேண்டிய மென்பொருட்களையோ (லைசன்ஸ்ட் வெர்ஷன்ஸ்) பயன்படுத்தலாம். 

புராஜக்ட்டின் முன்னேற்றத்தைக் கணக்கிடுவதற்குப் பல வகைகள் உண்டு. பத்து நாளில் செய்து முடிக்க வேண்டிய வேலை மூன்று நாள் முடிவில், 30% முடிவடைந்தது என சொல்ல முடியாது. தீக்குச்சி அடுக்குவது போன்ற ஒரே மாதிரியான வேலைக்கு மட்டுமே அப்படி கணக்கிட முடியும். மற்ற வேலைகளில் 10 நாள் வேலையில் மூன்று நாள் கடந்திருக்கிறதெனில் 30%  முயற்சி ( எஃபர்ட் ) செலவிடப்பட்டிருக்கிறது எனலாம்.  

எவ்வளவு முயற்சி செலவிடப்பட்டிருக்கிறது, எவ்வளவு நாட்கள் கடந்திருக்கின்றன என்பதை வைத்தும் புராஜக்ட் எவ்வளவு விழுக்காடு முடிந்திருக்கிறது என்பதை வரையறை செய்ய முடியாது. அதைக் கண்டுபிடிக்கத் தான் ஏற்கனவே நாம் “வர்க் பிரேக்டவுன் ஸ்ட்ரக்சர்” பற்றிப் படித்தோம். அந்த வேலைகளின் பட்டியலில் நாம் பதிவு செய்கின்ற, “என்னென்ன முடிந்திருக்கிறது, என்னென்ன எந்த அளவில் இருக்கிறது” போன்ற தகவலை வைத்தே புராஜக்ட் எத்தனை சதவீதம் முடிந்திருக்கிறது என்பதைச் சொல்ல முடியும்.

ஒவ்வொரு விஷயத்தையும் பதிவு செய்து வைப்பது புராஜக்டின் பயணத்துக்கும், அடுத்தடுத்த புராஜக்ட்களுக்கான திட்டமிடலுக்கும் பயனளிக்கும். ஒவ்வொருவரும் தங்களுடைய வேலைகளைக் குறித்துக் கவனமாய்ப் பதிவு செய்து கொண்டே வருவது, அவர்களுடைய இலக்கை தொடர்ந்து ஞாபகப்படுத்திக் கொண்டே இருக்கும். “அட சரியா தான் போயிட்டிருக்கேன்” என்று நமது பாதையை சரிபார்த்துக் கொள்ளவோ, “இன்னும் ஸ்பீடா போனா தான் வேலை முடியும்” என எச்சரிக்கை அடையவோ, “போற ரூடே தப்பாச்சே” என உஷாராகி ரூட்டை மாற்றவோ இந்த தொடர்ந்த கவனிப்புகள் உதவும். 

இதை எழுதும்போது ஒரு விமான விபத்து நினைவுக்கு வருகிறது. நூற்றுக்கும் மேற்பட்ட மக்களை பலிகொண்ட ஒரு விமான விபத்து அது. அதற்கான காரணத்தை அலசி ஆராய்ந்த போது அவர்கள் கண்டுபிடித்த விஷயம் அதிர்ச்சிகரமானது. ஒரு மெக்கானிக், விமான இறக்கை ஒன்றில் பொருத்த வேண்டிய ஸ்க்ரூவைப் பொருத்தியபோது அதன் “நட்” கழன்று விட்டது. ஆனாலும் ஸ்க்ரூ சரியாக ஸ்ட்ராங்காக இருக்கிறது என அவர் சென்று விட்டார். விமானப் பயணத்தின் போது அந்த ஸ்குரூ கழன்றது தான் அந்த மாபெரும் விபத்துக்குக் காரணம் என கடைசி அறிக்கை சொன்னது. ஒரு சின்ன விஷயம், ஒரு மாறா வரலாற்றுப் பிழையாய் மாறிப் போனது. அந்த சிறு பிழையை அப்போதே சரி செய்திருந்தால் நூற்றுக்கு மேற்பட்ட உயிர்கள் காப்பாற்றப்பட்டிருக்கும். 

தொடர்ந்து கவனிக்கும் போது தான் இத்தகைய சிறு சிறு பிரச்சினைகளை உடனுக்குடன் சரி செய்ய முடியும்.  கப்பலில் விழுந்த ஓட்டையைப் போல சில சின்ன பிரச்சினைகள் கடைசியில் புராஜக்டையே மூழ்கடித்து விடக் கூடும். எனவே இந்த கவனித்தல், சரிபார்த்தல், பதிவு செய்தல் போன்றவை சாதாரணமானவை என விட்டு விடாமல் மிகக் கவனமாக இருக்க வேண்டும்.

*

புராஜக்ட் மேனேஜ்மெண்ட் – மைக்ரோ கவனிப்பு

13

மைக்ரோ மேனேஜ்மென்ட் நல்லதா ?

*

நல்லதா ? கெட்டதா ? என்று கேட்கும் முன் “மைக்ரோமேனேஜ்மென்ட்” என்றால் என்ன என்பதைப் புரிந்து கொள்வது நல்லது. அதை ஒரு சின்ன உதாரணம் மூலம் சொன்னால் எளிதாகப் புரியும் என நினைக்கிறேன். சில மாமியார்கள் மருமகள்களிடம் சமையல் வேலையை ஒப்படைப்பார்கள். ஒப்படைத்து விட்டு வெளியே போகமாட்டார்கள். அப்படியே சமையலறையில் ஓரமாக நின்று விட்டு, “அந்த வாணலியை எடுக்காதே, இதை எடு” என்பார்கள். எடுத்ததும், “அதை கொஞ்சம் கழுவிடு” என்பார்கள். கழுவினால் கூட, “கொஞ்சம் ஓரத்தையெல்லாம் விம் போட்டு நல்லா தேச்சுடு” என்பார்கள். அப்புறம், “அடுப்பை சிம்ல போடு, இவ்ளோ ஃப்ளேம் வேண்டாம் என்பார்கள். இப்படி கூடவே நின்று ஒவ்வொரு சின்ன வேலையிலும் மூக்கை நுழைத்தால் எப்படி இருக்கும் ?

“என்கிட்டே சமையல் செய்ய சொல்லிட்டீங்கல்ல, நான் பாத்துக்கறேன்.. கொஞ்சம் வெளியே போறீங்களா ?” என கத்தத் தோன்றும் இல்லையா ? இப்படி சின்னச் சின்ன விஷயத்திலும் மூக்கை நுழைத்துக் கொண்டே இருப்பது தான் மைக்ரோ மேனேஜ்மென்ட் என்பது. ஒரு வேலையை திறமையான ஒருவரிடம் ஒப்படைத்தபிறகு அவருடைய ஸ்டைலில் அந்த வேலையைச் செய்ய விட்டு விட வேண்டும். “என்ன செய்ய வேண்டும்” என்பதைச் சொல்ல வேண்டுமே தவிர, “எப்படி செய்ய வேண்டும்” என்பதைச் சொல்லாமல் இருப்பதே நல்லது. அதிலும் குறிப்பாக ஒவ்வொரு விஷயத்தையும் கண்ணில் விளக்கெண்ணை ஊற்றிக் கவனிப்பது கூடவே கூடாது.

ஒரு மேனேஜர் மைக்ரோ மேனேஜ் செய்வதற்கு பல காரணங்கள் இருக்கலாம்.

1. எப்படியாவது அந்த புராஜக்டில் முழுமையாக ஈடுபட வேண்டும் என நினைக்கின்ற நபராக இருக்கலாம். எனவே புராஜக்டில் நடக்கின்ற ஒவ்வொரு விஷயங்களையும் கூடவே இருந்து பார்க்க வேண்டும் எனும் ஆர்வம் அவருக்கு இருக்கும். அந்த மனநிலை இருப்பவர்கள் மைக்ரோமேனேஜ் செய்யும் இயல்பைக் கொண்டிருப்பார்கள்.

2. சில வேளைகளில் புராஜக்டின் கடைசி கட்ட அப்டேட் வரை தனக்குத் தெரிய‌ வேண்டும் என நினைப்பவர்கள் இத்தகைய மைக்ரோமேனேஜ் மனநிலையைக் கொண்டிருப்பார்கள். எனக்குத் தெரியாம ஒரு துரும்பு கூட அசையக் கூடாது என்பவர்கள் பெரும்பாலும் மைக்ரோமேனேஜ்மென்ட் பார்ட்டிகளாகத் தான் இருப்பார்கள். அவர்களுடைய தலைவர் மைக்ரோமேனேஜ் மனநிலை கொண்டிருந்தால் சொல்லவே வேண்டாம், அது அப்படியே அடுத்தடுத்த நிலைகளுக்கும் தாவும்.

3. சிலர் வேலை செய்வதை ஒரு ஹாபியாகவே வைத்திருப்பார்கள்.அவர்களால் வேலை செய்யாமல் இருக்கவே முடியாது. அப்படிப்பட்டவர்கள் எப்போதுமே களத்தில் இறங்கி என்ன நடக்கிறது என்பதைக் கவனித்துக் கொண்டே இருப்பார்கள். எல்லா முடிவுகளிலும் தங்களுடைய தலையீடு இருக்கும்படி பார்த்துக் கொள்வார்கள். இப்படிப்பட்டவர்களால் சரியான டெலிகேட் செய்ய முடியாது.

4. சிலர் ‘நான் இதுல எக்ஸ்பர்ட், என்னைத் தவிர யாரும் இதை சிறப்பாகச் செய்ய முடியாது’ எனும் மனநிலை கொண்டிருப்பார்கள். அவர்கள் எப்போதுமே தங்களுடைய முடிவு தான் சரியான இருக்கும் என உறுதியாக நம்புவார்கள். தங்களுக்குத் தெரிந்த வழியைத் தவிர வேறு வழிகளில் சிறப்பாகச் செயல்பட முடியாது என நினைப்பார்கள். இப்படிப்பட்டவர்கள் மைக்ரோமேனேஜ்மென்ட் செய்யாமல் இருக்கவே மாட்டார்கள்.

5 சிலருக்கு எதுக்கெடுத்தாலும் சந்தேகம் இருக்கும். நான் சொன்னது அவர்களுக்குப் புரிந்திருக்குமா ? சரியாகச் செய்வார்களா ? புரியாமல் குழம்புவார்களா ? எனும் ஒரு பதட்டம் இருக்கும். அதனாலேயே அடிக்கடி எல்லா விஷயங்களிலும் மூக்கை நுழைத்துக் கொண்டே இருப்பார்கள்.

6. சிலருக்கு உள்ளூர ஒரு ‘பயம் இருக்கும்’.தன்னை விட அடுத்த நபர் நல்ல பெயரை வாங்கிவிடுவாரோ. தன்னுடைய பெயர் போய்விடுமோ. தன்னுடைய வேலைக்கு அந்த நபர் ஒரு வில்லனாய் வந்து விடுவாரோ போன்ற அச்ச உணர்வுகள் மைக்ரோமேனேஜ்க்குள் தள்ளி விடும்.

7. சிலருக்கு தங்களுடைய நேரத்தை எப்படிச் சரியாகப் பயன்படுத்துவது என்பது தெரியாது. அதனால் தேவையற்ற விஷயங்களில் நேரத்தைச் செலவிட்டுக் கொண்டே இருப்பார்கள். மைக்ரோமேனேஜ் தான் நல்லதுப்பா” என அவர்கள் வெளிப்படையாகவே சொல்வார்கள்.

மைக்ரோமேனேஜ்மென்ட் நல்லதல்ல என்பது ஒரு புறம் இருக்க, சில மேனேஜர்கள் மைக்ரோமேனேஜ்மென்ட் எனும் பூதக்கண்ணாடியோடு அலைவதை நாம் தவிர்க்கவே முடியாது என்பது தான் கள யதார்த்தம். அத்தகைய சூழல்களில் அந்த மேனேஜர்களோடு இணைந்து பணியாற்ற சில விஷயங்களை மனதில் கொள்ள வேண்டும்.

முதலாவது, மைக்ரோமேனேஜ் பொதுவாகவே நம்பிக்கையின்மையிலிருந்து தான் பிறப்பெடுக்கும். ‘கொடுத்த வேலையை இவன் ஒழுங்கா செய்வானா ? ” எனும் சந்தேகம் அதற்கான மூல காரணமாய் இருக்க வாய்ப்புகள் அதிகம். அத்தகைய சூழல்களில் எப்படி நாம் நம்பகத் தன்மையை உருவாக்குவது என்பதைப் பற்றி யோசிக்க வேண்டும்.

முதலில் புராஜக்ட் சார்ந்த அத்தனை விஷயங்களும் மேனேஜரைத் தெரியப்படுத்துவது உசிதம். “எதையோ மறைக்கிறான்” எனும் சந்தேகம் எழும்போது மைக்ரோமேனேஜ்மென்ட் பழக்கம் வலுவடையும். அத்தகைய சிந்தனை எழாமல் கவனித்துக் கொள்ள, வெளிப்படையான கம்யூனிகேஷன் அவசியம். அதற்காக சில மைல்கற்களை உருவாக்கி, அதை நிறைவேற்றும் விஷயத்தை தெளிவாக விளக்கலாம்.

மைக்ரோமேனேஜ் செய்யும் மேனேஜரை எதிர்ப்பதை விட்டு விட்டு, அவர் அதிக நேரம் செலவிடுவதற்காய் நன்றி சொல்லுங்கள். அவருடைய தலையீடு எந்த எதிர்ப்பையும் சம்பாதிக்கவில்லை என்பது தெரிந்தாலே, மெல்ல மெல்ல அந்த மனநிலை மாறிவிடும் என்பது தான் நிஜம். கேட்கும் முன்னரே தேவையான தகவல்களையெல்லாம் அவருக்குக் கொடுத்து விடுவது ரொம்ப பயனளிக்கும்.

உதாரணமாக மைக்ரோமேனேஜ் செய்பவர்களுடன் கொஞ்ச நாள் வேலை செய்தாலே அவர்கள் எப்படிப்பட்ட கேள்விகளைக் கேட்பார்கள் என்பது தெரிந்து விடும். டெய்லி சாயங்காலம் வந்து “அந்த பேய்மென்ட் எல்லாம் அனுப்பியாச்சா” கேப்பாரு, காலைல “யாரெல்லாம் என்ன பண்றாங்கன்னு” கேப்பாரு, “நேற்றைக்கு ஏதாச்சும் பென்டிங்கான்னு” கேப்பாரு இப்படி பல விஷயங்களை நாம் கண்டுபிடிக்க முடியும். இந்த பேட்டர்ன் புரிஞ்சு போச்சுன்னா, அதுக்குத் தக்கபடியான பதிலை நாம உருவாக்கிக் கொடுக்க முடியும். அவர் கேட்கும் முன்பாகவே, அவர் வழக்கமாகக் கேட்கும் கேள்விகளுக்கான பதிலை அவரிடம் கொடுத்து விட்டால் அவரது நம்பிக்கை அதிகரிக்கும்.

எதற்காக இந்த கேள்விகளையெல்லாம் கேட்கிறார் ? ஏன் ரொம்ப நோண்டறாரு ? என மனதில் கேள்விகள் அலை மோதலாம். அதற்கான பதிலை கண்டறிய முயலுங்கள். அது அவரது இயல்பாய் இருந்தால், அதை எதிர்கொள்ள அவரது வழியில் போக வேண்டும். ஒருவேளை உங்களிடம் மட்டும் தான் இப்படி நடந்து கொள்கிறார் எனில், உங்களிடம் அவருக்கு முழுமையான நம்பிக்கை இல்லை என்பது பொருள். அந்த நம்பிக்கையை உருவாக்க வேண்டும்.

நாமாகவே ஒரு கற்பனைக் கதையை உருவாக்கி அதில் வில்லனாக மேனேஜரை நிறுத்துவது தேவையில்லாத விஷயம். பெரும்பாலானவர்கள் செய்கின்ற இமாலயத் தவறு இது தான். ‘என் மேல மேனேஜருக்குத் தனிப்பட்ட விரோதம் அதான் நோண்டிட்டே இருக்காரு’ போன்ற சிந்தனைகளை முதலில் ஓரம் கட்ட வேண்டும். அதே போல‌, ‘இவரு கேக்கறதுக்கெல்லாம் நான் எதுக்கு பதில் சொல்லணும்’ எனும் ஈகோ சிந்தனைகளையும் முழுமையாய் ஒதுக்கி வைக்கவேண்டும். வேலை இடத்தில், கொடுக்கப்பட்ட வேலையை எப்படிச் செய்வது, எப்படி சுமூகமாகச் செய்வது, எப்படி சிறப்பாகச் செய்வது, எப்படி வேகமாய்ச் செய்வது போன்ற விஷயங்களைப் பற்றித் தான் சிந்திக்க வேண்டும்.

புராஜக்ட் மேனேஜ்மென்ட் பற்றிப் பேசும்போது இதைப் பற்றிப் பேசக் காரணம், பலரும் இதை எதிர்கொள்ளச் சிரமப்படுவார்கள் என்பது தான். எது எப்படியோ, ஒரு மேனேஜராக‌ மைக்ரோமேனேஜ் செய்வது சரியான வழிமுறையல்ல. ஆனால் அத்தகைய சூழல்களை முழுமையாய்த் தவிர்க்கவும் முடியாது என்பது தான் நாம் புரிந்து கொள்ள வேண்டிய விஷயம்.

*
சேவியர்

புராஜக்ட் மேனேஜ்மெண்ட் 12 : பணியைப் பகிர்.

12

பணியைப் பகிர்ந்தளித்தல் ( டெலிகேஷன் )

 

பணியைப் பகிர்ந்தளித்தல் ஒரு கலை. அது ஒரு பந்தைத் தூக்கிக் கிணற்றுக்குள் போடுவது போல் அல்ல. ஒரு கால்ப்பந்து விளையாட்டில் பந்தை ஒரு நபருக்கு பாஸ் செய்வது போல. அதன் பின் அந்த பந்தின் அடுத்த சில நீக்கங்கள், என்ன செய்ய வேண்டும் எனும் திட்டமிடல், சூழலுக்கு ஏற்ப விளையாடுதல், எதிராளியை எதிர்கொள்தல் என பல விஷயங்கள் பந்து யாரிடம் செல்கிறதோ அவரிடம் இருக்கும். அதே நேரத்தில் அவருடைய இறுதி இலக்கு என்பது அணியின் இலக்கு தான். அணிக்காக கோல் அடிப்பது, அணியை வெற்றியடையச் செய்வது என்பதாகத் தான் அந்த இலக்கு இருக்க வேண்டும். 

தனியே ஒரு நபர் என்ன தான் சிறப்பாக விளையாடினாலும் அணி தோல்வியடைந்தால் அந்த தனிப்பட்ட சாதனைகள் காணாமலேயே போய்விடும். விழலுக்கு இறைக்கின்ற நீரானது களஞ்சியங்களை நிரப்புவதில்லை. எனவே பணியைப் பகிர்ந்தளிக்கும் போது சரியான நபருக்கு அதை அளிப்பதும். பணியைப் பெற்றுக் கொண்ட நபர் ஒட்டு மொத்த நிறுவனத்தின் வெற்றியை மனதில் கொண்டே அந்த பணியை ஏற்றுக் கொள்வதும் மிக முக்கியமான அம்சங்கள்.

சில மேனேஜர்கள் வீட்டு அப்பாக்கள் போல. வீட்டு அப்பாக்கள் வேலைகளை அவர்கள் மனைவியிடமோ பிள்ளைகளிடமோ ஒப்படைப்பார்கள். ஆனால் சுதந்திரமாகச் செயல்பட விடமாட்டார்கள். முடிவு எடுக்கும் விஷயத்தை எல்லாம் தானே வைத்துக் கொண்டு, செயலை மட்டும் பிறர் செய்ய வேண்டும் என ஒப்படைப்பது சரியான அணுகு முறையல்ல. கால்பந்துக் களத்தில், ‘நான் இந்த பந்தை அங்கே அடிக்கவா ? இங்கே அடிக்கவா ?’ என கேட்டுக்கொண்டிருக்க முடியாது. ஒரு பொறுப்பை ஒருவரிடம் ஒப்படைக்கும் போது அந்தப் பணியைச் செய்வதற்கான முழு சுதந்திரத்தையும் அவரிடமே கொடுத்து விட வேண்டும். இதை டெலிகேஷன் வித் அதாரிடி என அழைப்பார்கள். 

உதாரணமாக, நீங்கள் ஒருவரிடம் ஒரு பணியை ஒப்படைக்கிறீர்கள் என வைத்துக் கொள்ளுங்கள். அவரிடம் நான்கு பேர் வேலை செய்கிறார்கள். அவரது குழுவில் இருக்கின்ற நபர்களுக்கு என்ன வேலை கொடுப்பது, எப்படி கொடுப்பது, எப்போது கொடுப்பது போன்றவற்றையெல்லாம் அவரே தீர்மானிக்க விட்டு விட வேண்டும். அதில் தலையிடக் கூடாது. அந்தக் குழுவிலுள்ள யாரேனும் உங்களிடம் வந்து, “அவரு இப்படி சொல்றாரு, அது சரியில்லையே” என சொன்னால் கூட ” உங்கள் தலைவர் சொல்வதை நீங்கள் செய்யுங்கள்” என தெளிவாகச் சொல்ல வேண்டும். அப்போது தான் நீங்கள் டெலிகேட் செய்த பணியை நிறைவேற்றும் சுதந்திரத்தை அவருக்குக் கொடுக்கிறீர்கள் என்று அர்த்தம். 

அவர் தன்னுடைய பணியைச் சரியாகச் செய்ய‌வில்லை என தோன்றினால் கூட அந்த நபரைத் தனியே அழைத்து நீங்கள் விவாதிக்கலாம், ஆலோசனைகள் சொல்லலாம். ஆனால் அவருக்குக் கொடுத்த பணியிலும் நீங்கள் தான் இறுதி முடிவை எடுக்கிறீர்கள் எனும் சூழல் உருவாகக் கூடாது. அது ஒரு பொம்மைத் தலைமையை வைத்துக் கொண்டு ஆட்சி நடத்துவதைப் போன்றதாகிவிடும்.

ஒரு வேலையை இன்னொருவரிடம் ஒப்படைப்பது அவ்வளவு எளிதான செயல் அல்ல. பைலட்டை நம்பி விமானத்தில் ஏறுவது போன்ற விஷயம் அது. பைலட்டின் முழு கட்டுப்பாட்டில் விமானப் பயணம் இருக்கும். அவர் சரியான முடிவெடுப்பார் என நம்ப வேண்டும். ஆனால் அதில் ஒரு ரிஸ்க் இருக்கிறது இல்லையா ? அதனால் தான் வேலையை டெலிகேட் செய்வதற்கு முன் சில விஷயங்களைக் கவனத்தில் கொள்ள வேண்டியது அவசியமாகிறது.

1. எந்த வேலையைக் கொடுக்கலாம். ?

உங்களுடைய பெரிய புராஜக்டின் “எந்த ஒரு பகுதியை” இன்னொருவருக்குக் கொடுக்கலாம் என்பதைப் பற்றிய முழுமையான புரிதல் அவசியம். அந்த வேலை கொண்டு வரவேண்டிய ரிசல்ட் என்ன ? எவ்வளவு காலத்தில் அதைச் செய்ய வேண்டியிருக்கும் ? எந்தெந்த குழுக்களுடன் அவர்கள் இணைந்து பணியாற்ற வேண்டியிருக்கும் போன்ற விஷயங்களெல்லாம் முதலில் நமக்குத் தெளிவாகத் தெரிய வேண்டும். 

என்ன வேண்டும் என்பது தெரியாமல் ஒரு வேலையை டெலிகேட் செய்ய முடியாது. ‘எனக்கு என்ன வேணும்ன்னு எனக்குத் தெரியல, ஆனா எனக்குத் தேவையானதை நீ கொண்டு வா” என ஹோட்டல் சர்வரிடம் ஆர்டர் செய்ய முடியாது. எனவே முதலில், எந்த வேலையைக் கொடுக்கலாம், அது தரவேண்டிய அவுட்புட்/விளைவு/ரிசல்ட் என்ன என்பதைப் பற்றிய புரிதல் வேண்டும்.

2. யாரிடம் கொடுக்கலாம் ?

இது தான் மிகப்பெரிய சவாலான கேள்வி. நமக்கு நன்றாகத் தெரிந்தவர் என்பதற்காகவோ, வேற யாருக்காவது கொடுத்தா பிரச்சினை வரும் என்பதற்காகவோ ஒரு வேலைக்கான நபரைத் தேர்ந்தெடுக்கக் கூடாது. அந்த குறிப்பிட்ட வேலைக்கு என்ன திறமை வேண்டும் ? அது இந்த நபரிடம் இருக்கிறதா ? இவரிடம் கொடுத்தால் அந்த வேலை நன்றாக முடியுமா ? இதற்கு முன் இத்தகைய வேலை எதையாவது இந்த நபர் செய்திருக்கிறாரா ? போன்ற அலசல்கள் தான் முதன்மைப்படுத்தப்பட வேண்டும். தனிநபர் விருப்பு வெறுப்புகளுக்கு இடம் கொடுத்தால் தவறான நபருக்கு வேலையைக் கொடுத்து கஷ்டப்பட வேண்டியிருக்கும்.

3. எப்படிக் கொடுக்கலாம் ?

ஒரு வேலையை ஒரு நபரிடம் கொடுக்கும் போது, அந்த நபருக்கும், தான் என்ன வேலை செய்யப் போகிறோம் என்பதைக் குறித்த தெளிவு வேண்டும். உங்களுக்கு பிரியாணி வேண்டும் என்பது தேவையாய் இருந்தால், அதை சர்வரிடம் தெளிவாகச் சொல்ல வேண்டும். உதாரணமாக, எனக்கு மட்டன் பிரியாணி வேண்டும், அதிலும் மலபார் மட்டன் பிரியாணி தான் வேண்டும், கத்தரிக்கா கொஞ்சம் எக்ஸ்ட்ரா வேண்டும் இப்படி மிகத் தெளிவாக நமது தேவைகளைச் சொல்ல வேண்டும். 

சொல்வதை எழுத்து மூலமாக ஒப்பந்தத்துக்குள் கொண்டு வருவதும் தேவையானது. இதன் மூலம் சந்தேகம் வரும்போது நமது, ‘ரிக்கொயர்மென்ட்/தேவை’ என்னவாய் இருந்தது என்பதை மறுபரிசீலனை செய்ய வசதியாய் இருக்கும். கடைசியாய் வேலை முடிந்த பிறகும், இதைக் கேட்டீர்கள் செய்திருக்கிறேன் என நமது வேலையை நியாயப்படுத்தவும் பயன்படும். 

4. வேலையைக் கண்காணித்தல். 

ஒரு வேலையை ஒரு நபரிடம் கொடுக்கிறோம். அவருக்கு சுதந்திரம் கொடுக்கிறோம். அவரை வேலை செய்ய ஊக்குவிக்கிறோம். அவரிடம் நமது தேவைகளைத் தெளிவாகச் சொல்கிறோம், இவையெல்லாம் மட்டுமே போதுமானது அல்ல. ஒரு கண்காணிப்பும் அவசியம். மதுரையிலிருந்து சென்னைக்குக் காரில் செல்கிறோம். டிரைவரிடம் பணியைக் கொடுத்தாகிவிட்டது. இனிமேல் நன்றாகக் குறட்டை விட்டுத் தூங்கி விடுவோம் என நினைக்க கூடாது.  அவ்வப்போது நாம் செல்கின்ற ரூட் சரியாக இருக்கிறதா என்பதைப் பார்க்க வேண்டும். அதைச் சாலையிலுள்ள மைல்கற்கள், வழிகாட்டும் பலகைகள் போன்றவற்றைக் கொண்டு புரிந்து கொள்ளலாம். 

ஓட்டுகிற டிரைவர் விழிப்பாக இருக்கிறாரா என பார்க்க வேண்டும். அவருக்கு சோர்வாக இருந்தால் தேவையான ஓய்வு கொடுத்து ஒரு டீ வாங்கி கொடுக்க வேண்டும். உற்சாகமூட்டிவிட்டு அவரை மீண்டும் பணியைத் தொடரச் செய்ய வேண்டும். அவரோடு கொஞ்ச நேரம் விழித்திருந்து பேச வேண்டுமெனில் அதற்கும் தயாராக இருக்க வேண்டும். வேலையைக் கண்காணித்தல் என்பது ஒரு கலை. அது வழிகாட்டுதலும், ஊக்கமூட்டுதலும், பாராட்டுதலும் கலந்ததாய் இருப்பதே சிறப்பானது. இப்படித்தான் புராஜக்ட் செல்லும் பாதை, வேகம், பணியாளர்களின் உடல்நிலை, மனநிலை அனைத்தையும் கவனிக்க வேண்டும்.  

5. பிரச்சினைகளுக்கு துணை நிற்பது.

ஒரு வேலையை ஒருவரிடம் ஒப்படைத்தபின் அவருக்கு வருகின்ற பிரச்சினைகளையெல்லாம் அவரே தான் பார்த்துக் கொள்ள வேண்டும் என கைகழுவும் வேலையை ஒரு புராஜக்ட் மேனேஜர் செய்யவே கூடாது. பிரச்சினைகள் வரும்போது கவனிக்க வேண்டும். அந்த நபருக்கு உங்கள் உதவி தேவைப்படும் சூழலில் நீங்கள் முழுமையாக களமிறங்க வேண்டும். அது ஒரு வேலையை முடிப்பதற்குத் தேவையான ஆட்களைக் கொடுப்பதாக இருந்தாலும் சரி, பணம் கொடுப்பதாக இருந்தாலும் சரி, ஆலோசனை கொடுப்பதாக இருந்தாலும் சரி. நமது பங்களிப்பை முழுமையாய்க் கொடுக்க வேண்டும். 

சென்னைக்குப் போய்க்கொண்டிருக்கும் வண்டி வழிமாறி வேறெங்கோ சென்றுவிட்டதென டிரைவர் சொன்னால், “அறிவில்லையா ? ஒழுங்கா பாத்து ஓட்ட மாட்டே ? நான் எப்போ ஊர் போய் சேருவது ?” என கத்துவதல்ல சரியான வழி. முதலில் டிரைவரை இயல்பு நிலைக்குக் கொண்டு வந்து. என்ன பிரச்சினை, இப்போது எங்கே நிற்கிறோம் என்பதைப் புரிந்து கொண்டு. இனிமேல் சரியான வழிக்கு வர என்னென்ன செய்ய வேண்டும் என்பதை தீர்மானித்து டிரைவருக்கு உதவுவது தான் சரியான வழி.

“கவலைப்படாதே, நாம அந்த ரோடைப் புடிச்சா திருச்சி போயிடலாம். கொஞ்சம் சுத்து தான் பரவாயில்லை. பெட்ரோல் இருக்கா பாத்துக்கோ.மறுபடி கன்ஃப்யூஷன் ஆயிடுச்சுன்னா என்கிட்டே சொல்லு” என சொல்வது சரியான வழிமுறை. புராஜக்ட் முடிந்தபின் என்னென்ன தவறுகள் செய்தோம், அதை எப்படி தவிர்த்திருக்கலாம் என்பதைப் பற்றியெல்லாம் சிந்திக்கலாம், ஓடிக்கொண்டிருக்கும் வண்டியில் டயர் மாற்றுவதும், புராஜக்டின் பாதியில் தவறுகளைக் குறித்து தர்க்கமிடுவதும் ஆபத்தானவை. 

( தொடரும் )

புராஜக்ட் மேனேஜ்மெண்ட் 11 :

11

உன்னால் முடியும் தம்பி…

ஒரு புராஜக்டின் வெற்றிக்கு மிக முக்கியமான அம்சம் பணியாளர்கள் என்பதை நாம் ஏற்கனவே பார்த்தோம். அந்தப் பணியாளர்களை எப்படி வகை பிரிப்பது, எப்படி வேலை வாங்குவது என்பதெல்லாம் ஒரு கலை. புராஜக்ட் மேனேஜ்மென்டின் மிக முக்கியமான பணிகளில் இதுவும் ஒன்று.

நம்மிடம் யாரெல்லாம் இருக்கிறார்கள் ? அவர்களுக்கு என்னென்ன வேலைகள் கொடுக்கலாம் என சிந்திப்பது சரியான வழியல்ல. ஒரு புராஜக்டிற்கு என்னென்ன வேலைகள் இருக்கின்றன ? அதற்கு எப்படிப்பட்ட நபர்கள் தேவைப்படும் என சிந்திப்பதே சரியான வழியாகும்.

புராஜக்டில் பணிபுரியும் எல்லா நபர்களுக்கும் அவர்கள் என்ன செய்யப் போகிறார்கள் என்பதைக் குறித்த தெளிவு இருக்கவேண்டும். ஒவ்வொரு வேலையிலும் பணியாளர்களின் நிலை என்ன என்பதை மூன்று பெரிய பிரிவுகளின் கீழ் வகைப்படுத்தலாம்.

1 அதாரிட்டி ( அதிகாரம் ). யாருக்கு புராஜக்டில் அதிகாரம் இருக்கிறது. அல்லது ஒரு குறிப்பிட்ட பணியில் யாருக்குஅதிகாரம் இருக்கிறது என்பதை இது குறிப்பிடுகிறது.

2. ரெஸ்பான்சிபிலிடி ( கடமை ). ஒரு வேலையை முடித்துக் கொடுக்க வேண்டும் எனும் கடமை யாருக்கு இருக்கிறது என்பதை இது குறிப்பிடுகிறது.

3. அக்கவுன்டபிலிடி ( பொறுப்பு ). வேலையைச் சரியாக முடிக்காவிட்டால் அதன் பழியும், வேலை சரியாக முடிந்துவிட்டால் அதன் பாராட்டும் யாருக்கும் கிடைக்கும் என்பதை இது குறிப்பிடுகிறது.

இப்படி மூன்று பெரும் பிரிவுகளை மனதில் வைத்துக் கொள்ளுங்கள். இப்போது ஒவ்வொரு பணிக்கும் தேர்ந்தெடுக்கப்படும் நபர்களுக்கு இதில் எது பொருந்தும் என்பதைப் பார்க்கவேண்டும்.

உதாரணமாக ஒரு வீடு கட்டும் புராஜக்ட் இருக்கிறது என வைத்துக் கொள்ளுங்கள். அதற்கான செலவு எவ்வளவு என்பதை நிர்ணயம் செய்வதும், அதிகமாகச் செலவு செய்யலாமா என்பதை முடிவெடுப்பதும், வீட்டை இன்னும் கொஞ்சம் பெரிதாகக் கட்டலாமா எனும் மாற்றங்களை செய்வதும் உரிமையாளருக்கு மட்டுமே இருக்கும். அவர் தான் அதாரிடி பர்சன். அவருடைய அனுமதியில்லாமல் அந்த பணிகளை இன்னொரு நபர் எடுத்துக் கொள்ள முடியாது, அல்லது எடுத்துக் கொள்ளக் கூடாது.

இரண்டாவது ரெஸ்பான்சிபிலிடி என்பதை பணியாளர்களோடு இணைக்கலாம். ஒழுங்காகக் கட்டிடத்தைக் கட்டி முடிக்க வேண்டியது கொத்தனார், எலக்ட்ரீஷியன், பிளம்பர் போன்ற அனைத்து பணியாளர்களுக்கும் உரிய கடமை. ஒவ்வொருவருக்கும் அவரவர் ஏரியாவில் ரெஸ்பான்சிபிலிடி எடுத்துக் கொள்வார்கள்.

மூன்றாவதான அக்கவுன்டபிலிட்டியை மேற்பார்வையாளருக்குக் கொடுக்கலாம். ஒரு வீடு சரியாக அமைந்தால் முதல் பாராட்டைப் பெறுவது அதன் மேற்பார்வையாளர் தான். அதே போல வீடு சரியான நேரத்தில் முடியாமல், சரியான பட்ஜெட்டில் முடியாமல் இருந்தால் அதன் பழியைச் சுமக்க வேண்டியதும் இந்த நிர்வாகி தான்.

இது ஒரு எளிய உதாரணம். ஒவ்வொரு புராஜக்டிலும் பல்வேறு பணிகள் இருக்கும். ஒவ்வொரு பணிக்கும் சிலர் அக்கவுண்டபிளாக, அதே பணிக்கு வேறொருவர் ரெஸ்பான்சிபிளாக, இன்னொருவர் அதிகாரமுடையவராக இருப்பார்.

இந்த பணிகள் பெரும்பாலும் ஒருவரிடமிருந்து ஒருவருக்கு மாறிக் கொண்டே இருக்கும். அதை டெலிகேஷன் என்பார்கள். உதாரணமாக “போய் மீனு வாங்கிட்டு வாங்க” என மனைவி கூடையை நம்மிடம் கொடுத்து விரட்டுகிறார் என வைத்துக் கொள்வோம். மீனை ஒழுங்காகப் பார்த்து வாங்க நமக்குத் தெரியாது. நாம் அடுத்த வீட்டு அம்மாவிடமோ, அல்லது மீன்வாங்குவதில் பழக்கமுள்ள நண்பரிடமோ அந்த வேலையை ஒப்படைப்போம். அவர்கள் வாங்கித் தருவதை மனைவியிடம் ஒப்படைப்போம்.

இதில் கவனிக்க வேண்டிய விஷயம் என்னவென்றால், மீன் சரியாக வாங்கவில்லையேல் பழி உங்களைத் தான் சேரும். நீங்கள் வேலையை செய்ய கண்டுபிடித்த அந்த பிரதிநிதிக்கு அல்ல ! நல்ல மீன் வாங்கினா பாராட்டும் உங்களுக்குக் கிடைக்கும். அதாவது, வேலையை வேறொருவருக்குக் கொடுத்தாலும் ‘என்ன வாங்க வேண்டும்’ ‘எப்படிப்பட்ட மீன் வாங்க வேண்டும்’, ‘எத்தனை ரூபாய்க்கு வாங்கவேண்டும்’ போன்ற அனைத்து விஷயங்களையும் மிகத் தெளிவாக அடுத்த நபரிடம் சொல்ல வேண்டிய கடமை உங்களுக்கு உண்டு. அதில் எந்த பிழை ஏற்பட்டாலும் கடைசியில் அவர் உங்கள் மனைவிக்குப் பிடிக்காத மீனை வாங்கி வந்து உங்கள் நிலமையை சட்னியாக்கக் கூடும்.

நிறுவனங்களில் இதை ஷேர்ட் ரெஸ்பான்சிபிலிடி என்பார்கள் அதாவது பகிர்ந்தளிக்கப்படும் பொறுப்பு. மீன் வாங்க வேண்டிய முதன்மைப் பொறுப்பு உன்னுடையது. அதை நீ இன்னொருவருக்குக் கொடுத்ததால் அவரும் அந்த ரெஸ்பான்சிபிலிட்டியை பங்கு வைக்கிறார் என்பது தான். அதாவது அடிவாங்க கூட ஒருத்தன் இருப்பான் அவ்ளோ தான்.

அதனால் தான் இந்த டெலிகேஷன் வேலை மிகவும் முக்கியமானதாகக் கருதப்படுகிறது. ஒரு வேலையை டெலிகேட் செய்ய வேண்டுமெனில் புராஜக்ட் மேனேஜருக்கு இரண்டு விஷயங்கள் மிகத் தெளிவாகத் தெரிந்திருக்க வேண்டும். ஒன்று என்ன வேலை செய்ய வேண்டும் என்பது. இரண்டாவது, யார் இந்த வேலையை சிறப்பாகச் செய்வார் என்பது. முன்பு ஒரு முறை நாம் பணியாளர்களின் திறமைப் பட்டியல் பற்றிப் பேசினோம், அது இங்கே பயன்படும்.

சரியாக டெலிகேட் செய்யத் தெரியாத புராஜக்ட் மேனேஜர் இரண்டு விதமான சிக்கல்களில் விழுந்து விடுவார். ஒன்று, தவறான நபருக்கு வேலையைக் கொடுத்து பிரச்சினைகளைச் சந்திப்பார். அல்லது, தானே வேலையைச் செய்கிறேன் என இழுத்துப் போட்டு ஒரு வேலையில் மட்டும் கவனம் செலுத்தி முக்கியமானதை கோட்டை விடுவார்.

ஒரு புராஜக்ட் மேனேஜர் எந்த அளவுக்கு குறைந்த வேலைகளை செய்கிறாரோ, அந்த அளவுக்கு அவருக்கு ஒட்டுமொத்த புராஜக்டின் பணிகளையும், வளர்ச்சிகளையும் கவனிக்க நேரம் கிடைக்கும். எல்லா வேலைகளையும் டெலிகேட் செய்ய முடியாது. சில வேலைகளை புராஜக்ட் மேனேஜர் தான் செய்ய வேண்டும் அதை அவர் டெலிகேட் செய்யக் கூடாது. உதாரணமாக மேனேஜருக்கு ஒரு ரிப்போர்ட் கொடுப்பதோ, கணக்கு வழக்குகளை சமர்ப்பிப்பதோ அவருக்கு மட்டுமே அனுமதிக்கப்பட்ட பணியாய் இருக்கலாம்.

மற்ற வேலைகளில் எதை எப்படி டெலிகேட் செய்யலாம் என்பதைக் கண்டுபிடிக்கவும் சில உத்திகள் உண்டு. முதலாவது ‘எதில் நான் பெஸ்டோ அதைச் செய்வது’. என்னால் மிகச் சிறப்பாகச் செய்யமுடியும், பல ஆண்டுகளாக இதைச் செய்து வருகிறேன் என்பது போன்ற ஸ்பெஷாலிடி விஷயங்களை புராஜக்ட் மேனேஜரே செய்ய வேண்டும். அதே போல, பெரிய அளவு பாதிப்பை ஏற்படுத்தாத பணிகளை புராஜக்ட் மேனேஜர் செய்யலாம். இதன்மூலம் அவருடைய மற்ற பணிகள் எதுவும் பாதிக்கப்படாது. இன்னொன்று, என்ன எதிர்பார்க்கிறோம் என்பதை மிகத் தெளிவாக விளக்காமல் எந்த ஒரு வேலையையும் டெலிகேட் செய்யவே கூடாது.

ஒரு வேலைக்கு தனக்குப் பதிலாக இன்னொருவரை அமர்த்தும் டெலிகேஷனில் ஆறு நிலைகள் உண்டு.

1. தெரிந்து வா ! ஒரு விஷயத்தைப் பற்றித் தெரிந்து வருவதற்காக ஒருவரை நியமிக்கலாம். நாம் பல இடங்களில் அலைந்து தகவல்களைச் சேமிக்க நேரம் இல்லாத பட்சத்தில் இப்படி ஒரு வேலை பகிர்தல் பயந்தரும்.

2. காண்பி ! ஒரு விஷயத்தை எப்படிச் செய்வது என்பதை அலசி ஆராய்ந்து அதன் வழிகளைக் காண்பிப்பது. இதில் பொதுவாக ஒன்றுக்கும் மேற்பட்ட வழிவகைகள் இருக்கும்.

3. நான் சொல்லும்போது செல் ! எனது அனுமதிக்காகக் காத்திரு, நான் சொன்னவுடன் நீ உன்னுடைய வேலையை ஆரம்பி என்பது தான் இது. நான் சொல்லும் வரை நீ செல்லக் கூடாது எனும் மறைமுக எச்சரிக்கையும் இதில் உண்டு.

4. சொல்லும்போ நில் ! நீ உன் வேலையைப் பாத்துட்டேயிரு, நான் ‘நிறுத்து’ ந்னு சொன்னா நீ நிறுத்திட்டா போதும் என்பது இந்த வகை.

5. எப்டி போவுது ? ஒரு வேலையை அலச வேண்டும், என்ன செய்ய வேண்டும் என அறிய வேண்டும், எப்படிச் செய்ய வேண்டும் என்பதை முடிவு செய்ய‌ வேண்டும், பின் என்ன முன்னேற்றம் என்பதை கவனிக்க வேண்டும்.

6. செல் : இது ஒரு முழுமையான டெலிகேஷன். இதான்பா வேலை, நீ என்ன செய்வியோ ஏது செய்வியோ தெரியாது எனக்கு இந்த ரிசல்ட் வேணும் என சொல்வது இது.

ஒரு வேலையை இன்னொருவரிடம் ஒப்படைப்பதில் இத்தனை விஷயங்கள் உள்ளன. “என் மேனேஜர் ஒரு வெட்டி, என்ன வேலை வந்தாலும் என் தலையில கட்டிவிடுவாரு” என சொல்வது எவ்வளவு அபத்தம் என்பதை அடுத்த வாரமும் பார்ப்போம்.

( தொடரும் )

புராஜக்ட் மேனேஜ்மெண்ட் 10 – அணி

10

அணி கட்டமைப்பு

ஒரு நிறுவனத்தின் வெற்றிக்கு முதுகெலும்பாய் அமைவது சந்தேகத்துக்கிடமின்றி பணியாளர்கள் தான். என்னதான் கலர் கலரா விளம்பரம் செஞ்சாலும், வேலை செய்றது பணியாளர்கள் தான். அவர்கள் திறமையானவர்களாக, நேர்மையானவர்களாக, அர்ப்பணிப்புடையவர்களாக இருக்கும் போது ஒரு நிறுவனம் வெற்றியின் பாதையில் வீறு நடை போடும். இல்லையேல் எல்லாம் விழலுக்கு இறைத்த நீராகும்.

நிறுவனத்திலுள்ள பணியாளர் மேலாண்மை பற்றி சுருக்கமாக ஏற்கனவே பார்த்தோம். அதில் பணியாளர்களின் பலம் பலவீனம் போன்றவற்றைத் தெரிந்து வைத்திருப்பது, புராஜக்டின் வெற்றிக்குத் தக்கபடி அவர்களை சரியாகப் பயன்படுத்துவது போன்றவை முக்கியமானவை. இந்த வாரம் அவர்களை எந்த முறையில் நிறுவனங்கள் குழு பிரிக்கின்றன, அதன் பயன்கள் பலவீனம் என்ன ? ஒரு புராஜக்ட் மேனேஜராக இவற்றை எப்படிக் கையாளவேண்டும் போன்றவற்றை இந்த வாரம் பார்ப்போம்.

முக்கியமாக நிறுவனங்கள் தங்கள் பணியாளர்களை மூன்று விதமான அணி அமைப்பில் நிறுத்துகின்றன.

1. ஃபங்ஷனல் ஸ்ட்ரக்சர் ( செயல் சார்ந்த அமைப்பு )
2. புராஜக்ட் ஸ்ட்ரக்சர் ( திட்டம் சார்ந்த அமைப்பு )
3. மேட்ரிக்ஸ் ஸ்ட்ரக்சர் ( இரண்டும் கலந்த அமைப்பு )

முதலாவதாய் வருகின்ற செயல் சார்ந்த அமைப்பில், ஒரே மாதிரியான பணி செய்கின்ற அனைவரும் ஒரு அணியின் கீழ் நிறுத்தப்படுவார்கள். அவர்களுக்கென ஒரு செயல் தலைவர் இருப்பார். குழுவில் அந்த குறிப்பிட்ட செயலைச் செய்யக் கூடிய பணியாளர்கள் மட்டும் இருப்பார்கள்.

உதாரணமாக, ஒரு வீடு கட்டும் வேலை நடக்கிறது என வைத்துக் கொள்ளுங்கள். கட்டுமானப் பணி செய்பவர்கள் எல்லாரும் ஒரு குழுவாக இருப்பார்கள். அவர்களுக்கென ஒரு தலைமை கொத்தனார் இருப்பார். எல்லோரும் அது சார்ந்த பணிகளை மட்டுமே செய்வார்கள். இது முதல் வகை.

இதிலுள்ள முக்கியமான நன்மை என்னவென்றால், எங்கே ஸ்பெஷலிஸ்ட் இருக்கிறார் என்பது நமக்குத் தெரியும். ஒரு கொத்தனார் வேணுமா, அந்த தலைவரிடம் கேட்டால் போதும் என எல்லோருக்கும் தெரியும். அந்த கொத்தனாரும் அனுபவஸ்தராக இருப்பதால் அவருக்குக் கீழே இருக்கும் அத்தனை பேரையும் சரியாய் வழிநடத்தவும் அவரால் முடியும். அதே போல எல்லாரும் சேர்ந்து ஒருங்கிணைந்து கட்டுமான வேலையை அழகாகச் செய்வார்கள்.

இது நல்லா தானே இருக்கு ? இந்த அமைப்பே போதுமே என நீங்கள் நினைக்கக் கூடும். இதில் சில நெகட்டிவ் விஷயங்களும் உண்டு. இப்படி இருக்கின்ற குழுக்களுக்கும், பிற குழுக்களுக்கும் இடையே சரியான புரிதல் பெரும்பாலும் இருக்காது. ஒரு புராஜக்ட்டுக்கு இந்த புரிதல் மிக மிக அவசியமானது.

உதாரணமாக, கொத்தனாரும் எலக்டிரீஷியனும் பேசிக்கொள்ளவில்லையேல், பைப் வைக்க வேண்டிய இடத்தில் சரியான நேரத்தில் பைப் வைக்க முடியாமல் போய்விடும். கொத்தனாரும் பிளம்பரும் பேசிக்கொள்ளவில்லையேல் அதற்கான ஆப்ஷன்கள் சரியாக அமையாமல் போய்விடும். கொத்தனாரும், டிசைனரும் பேசிக்கொள்ளவில்லையேல் வீட்டின் அழகை அது பாதிக்கும்.

இந்த செயல் குழுவின் இன்னொரு நெகடிவ் விஷயம் என்னவென்றால், ஒவ்வொருவரும் அவரவர் வேலையை முடிக்க வேண்டும் என்று தான் பார்ப்பார்களே தவிர, ஒட்டு மொத்த வீடு சரியாக முடியவேண்டும் என பார்க்க மாட்டார்கள். சுவரு கட்றது என் வேலை முடிச்சுட்டேன், அதுல நீ பெயின்ட் அடிப்பியோ அடிக்காம போவியோ அது எனக்குத் தேவையில்லாத விஷயம் எனும் மனநிலை இவர்களிடம் இருக்கும்.

ஐடியில் இந்த சிக்கல் மிகப்பெரிய அளவில் உண்டு. டெவலப்மென்ட், டெஸ்டிங், நெட்வர்க், கிளவுட் என ஒவ்வொரு குழுவும் மாறி மாறி குறை சொல்லிக் கொண்டே இருப்பது இங்கே சர்வ சாதாரணம். காரணம் ஒவ்வொருவரும் தங்கள் பாகத்தை மட்டுமே பார்ப்பார்கள், ஒட்டு மொத்த புராஜக்டை அல்ல.

இந்த வகை அமைப்பில், இன்னொரு குழுவினரின் ஒப்புதலை வாங்குவது ரொம்ப கடினம். என் வேலை முடியாம நான் ஒண்ணும் செய்ய மாட்டேன் எனும் மனநிலை மேலோங்கும். என்னோட வேலைக்கு இடையிலே உனக்கு எலக்ட்ரிக்கல் செய்ய நான் நேரம் ஒதுக்க முடியாது என கட்டுமானப் பணியாளர் சொல்வது போன்றது இது.

ஓ, இதுல இவ்ளோ பிரச்சினை இருக்கா ? நமக்குத் தேவை புராஜக்ட் தான். அதனால ஒவ்வொரு புராஜக்டுக்கும் தக்கபடி ஒரு அணியை உருவாக்குவோம் எனும் சிந்தனை தான் “புராஜக்ட் ஸ்ட்ரக்சர்”. இதில் பல விதமான பணி செய்பவர்கள் ஒரே தலைமையின் கீழ் இயங்குவார்கள். அந்த தலைவர் புராஜக்டை நடத்திச் செல்வார்.

உதாரணமாக, வீடுகட்டுவது ஒரு புராஜக்ட் எனில், கொத்தனார், பெயின்டர், பிளம்பர், எலக்ட்ரீஷியன் என எல்லோருமே ஒரு தலைவரின் கீழ் இயங்குவார்கள். புராஜக்ட் மேனேஜர் தனது பணியான வீட்டை நல்ல முறையில் முடிக்க வேண்டும் என்பதைப் பார்ப்பார். தனித்தனி குழுக்களாக மக்களைப் பார்க்க மாட்டார். அவரிடம் தான் எவ்வளவு பணம் செலவு செய்யலாம், எதை முதலில் செய்யலாம், எதை இரண்டாவது செய்யலாம் போன்ற முடிவெடுக்கும் உரிமை இருக்கும்.

இதில் கொத்தனார் தலைமைக் கொத்தனாரிடம் அல்ல, புராஜக்ட் மேனேஜரிடம் தான் வேலையைப் பெற்று அப்டேட்டையும் கொடுப்பார். அதே போல ஒவ்வொரு பணி செய்பவர்களும் தனித்தனியே புராஜக்ட் மேனேஜரிடம் தான் தங்கள் வேலைகளைப் பெற்று அதன் நிலையையும் சொல்வார்கள்.

எல்லோருக்கும் ஒரே தலைவர் என்பதால் குழுவிலுள்ள நபர்களிடையே நல்ல புரிதல் இருக்கும். தகவல் பரிமாற்றம் இயல்பாக இருக்கும். எல்லோருமே வீடு கட்டி முடியவேண்டும் எனும் கடைசி இலக்கை நோக்கிப் பயணிப்பார்கள்.

இது நல்லாயிருக்கே.. என நினைக்கும் முன் இதிலும் சில குறைகள் உண்டு என்பதைப் புரிந்து கொள்ள வேண்டும். முக்கியமாக ஒரு புராஜக்ட்டில் நல்ல திறமையான நபர் இருந்தால் அவர் அந்த புராஜக்டை மட்டும் தான் பார்ப்பார். ஒவ்வொரு புராஜக்டுக்கும் நிறைய ஆட்கள் தேவைப்படுவார்கள்.அதனால் செலவு அதிகமாகும்.

உதாரணமாக, கொத்தனாருக்கு ஒரு நாள் வேலை இன்றால் அவரை சும்மா வைத்திருக்க வேண்டும். வேறு எதுவும் செய்ய முடியாது. அதே போல ஒரு புராஜக்ட் முடிந்து விட்டால் அந்த புராஜட்டில் உள்ள நபர்களை என்ன செய்வது என்பதும் ஒரு மிகப்பெரிய கேள்விக்குறியாகும்.

இந்த இரண்டு முறைகளிலும் உள்ள குறைகளைக் களைவதற்காகத் தான் மேட்ரிக்ஸ் அமைப்பு உருவானது. இது கடவுள் பாதி, மிருகம் பாதி போல கலந்து செய்யப்பட்ட முறை. செயல்வடிவ அமைப்பும் இருக்கும், புராஜக்ட் அமைப்பும் இருக்கும். பணியாளர்கள் செயல் அமைப்பின் கீழ் இருப்பார்கள். அதாவது கொத்தனார்கள் எல்லாம் ஒரு தலைவரின் கீழ், பெயிண்டர் எல்லாம் இன்னொரு தலைவரின் கீழ் அப்படி.

அங்கிருந்து ஒவ்வொரு புராஜக்டுக்கும் தேவையான நபர்கள் அணி திரட்டப்பட்டு ஒரு புராஜக்டில் இணைவார்கள்.அந்த வேலை முடிந்ததும் மீண்டும் செயல் அணிக்குத் திரும்புவார்கள். ஒரு நபரே வேறு வேறு புராஜக்ட்களில் தேவைக்கேற்ப பணிபுரிவார்கள். உதாரணமாக ஒரு அனுபவம் வாய்ந்த பணியாளர் இருக்கிறாரெனில் அவர் ஒரே புராஜக்டில் பணி புரிய வேண்டிய அவசியம் இல்லை.

அதே போல ஒரு புதிய புராஜக்ட் வந்தாலும் தேவையான ஆட்களை பல குழுக்களிலிருந்தும் மிக விரைவாக பெற்றுக் கொள்ளவும் முடியும். இதிலுள்ள மிகப்பெரிய சவால், ஒரு நபரே இரண்டு தலைவரின் கீழ் வேலை பார்க்க வேண்டிய சூழல் உருவாகும்.

இப்போது பெரும்பாலான நிறுவனங்கள் மெட்ரிக்ஸ் அணியமைப்பைத் தான் கொண்டிருக்கின்றன. இந்த முறையில் புராஜக்ட் மேனேஜரின் பணி மிக மிக முக்கியத்துவம் வாய்ந்ததாகிறது. திட்டம் தீட்டுவது, எப்படிப்பட்ட நபர் வேண்டுமென முடிவெடுப்பது, ஒரு நல்ல டீமை அமைப்பது, விரிவான செயல்திட்டம் உருவாக்குவது, திட்டத்துக்கு ஏற்ப வேலை நடக்கிறதா என்பதைக் கண்காணிப்பது, செலவுகளை கண்காணிப்பது, புராஜக்டில் வருகின்ற மாற்றங்களை எதிர்கொள்வது என சர்வமும் புராஜக்ட் மேனேஜரின் தலையில் தான்.

மிக மிக முக்கியமாக மற்ற தலைவர்களுடன் நல்ல ஒரு புரிதலும், தொழில் ரீதியான நட்புறவும் இருக்க வேண்டியது அவசியம்.

( தொடர்வோம் )

புராஜக்ட் மேனேஜ்மெண்ட் 9 – ரிஸ்க்

9

ரிஸ்க் மேனேஜ்மென்ட்

போனவாரம் ஒரு புராஜக்ட்டுக்கு வரக்கூடிய ஆபத்துகளைக் குறித்த அடிப்படை விஷயங்களைப் பார்த்தோம். இந்த வாரம் அதைப்பற்றி இன்னும் கொஞ்சம் விரிவாக‌ அலசலாம். காரணம், ஒரு புராஜக்டின் வெற்றிக்கு, எதிர்பாரா ஆபத்தை எப்படி எதிர்கொள்கிறோம் என்பது மிக மிக முக்கியம்.’

ஒரு புராஜக்டின் ஏதோ ஒரு பகுதிக்கு வரக்கூடிய ஆபத்தை, ஒட்டு மொத்த புராஜக்டின் வெற்றியோடு ஒப்பிட்டுப் பார்க்க வேண்டியது மிக மிக அவசியம்.கிரிக்கெட் விளையாட்டில் ஒரு நபர் சொதப்பினாலும் டீம் தோற்றுப் போவதைப் போல, ஒரு சில ரிஸ்க்கள் போதும் ஒரு புராஜக்டை முடக்க. ஒரு புராஜக்டில் ஒருவேளை பத்து நிலைகள் இருக்கலாம். இந்த ரிஸ்க் எந்த இடத்தில் வருகிறது என்பதைப் பொறுத்து அடுத்தடுத்த நிலைகளில் பாதிப்பு உருவாகும்.

வயலில் விதைத்தால் தான் விவசாயம் செய்ய முடியும் என்பது ஒரு நிலை. விதைப்பதில் தாமதம் ஏற்பட்டால் அது அடுத்தடுத்த நிலைகளிலும் பாதிப்பை உருவாக்கலாம். ஒருவேளை தாமதமாய் விதைத்தால் தண்ணீர் கிடைக்காமல் போகலாம். ஒரு ரிஸ்க் இன்னொரு ரிஸ்கை உருவாக்கும் சூழல் அப்போது உருவாகும். அல்லது அறுவடை காலத்தில் சரியான வேலையாட்கள் கிடைக்காமல் போகலாம், அப்படியெனில் அதை எப்படிக் கையாள்வது என்பது தெரிய வேண்டும்.

ஒன்றுக்கொன்று தொடர்பில் இருக்கின்ற பணிகளில் ஒன்று தாமதமானாலும் அடுத்தடுத்த பணிகளில் அது பெரிய பாதிப்பை உருவாக்கும் என்பதே நாம் புரிந்து கொள்ள வேண்டிய விஷயமாகும். எனவே எந்த இடத்தில் ரிஸ்க் வந்தாலும், அது புராஜக்டின் முடிவு தேதியை எப்படிப் பாதிக்கிறது என்பதைக் கவனிக்க வேண்டும்.

ரிஸ்க் களுக்கான திட்ட வரைவு செய்யும் போது முடிந்தமட்டும் பொதுப்படையாக இல்லாமல் தெளிவான திட்டமாக உருவாக்க வேண்டியது அவசியம். உதாரணமாக, அருள் என்பவர் புராஜக்டின் முக்கியமான கட்டத்தில் விலகிவிட்டால் அந்த வேலையை ஆன்டனி என்பவரை வைத்துச் செய்ய வேண்டும். இதில் தெளிவாக, ஒரு நபருக்குப் பதில் இன்னொரு நபர் என்பதையும், அவர் யார் என்பது ஏற்கனவே முடிவு செய்யப்பட்டு விட்டது என்பதையும் நாம் திட்டமிடுகிறோம். அது தான் தெளிவான திட்ட வரைவு. அருள் இல்லையேல், வேறொருவரை வைத்து வேலையை முடிப்போம் என்பது சரியான திட்ட வரைவு அல்ல. அது பொதுப்படையான ஒரு திட்டம் அவ்வளவு தான்.

ரிஸ்க் திட்டத்துக்கு பல வழிகள் உண்டு. உதாரணமாக, டிசிஷன் ட்ரீ என்பது ஒரு முறை. ஒவ்வொரு ரிஸ்க் விஷயத்தையும் எழுதி, அது நடந்தால் என்ன பாதிப்பு என்பதையும் எழுத வேண்டும். அதை ஒரு கிளை விரித்துப் பரவும் மரத்தைப் போல படிப்படியாய் வரைய வேண்டும். அதிலிருந்து அந்த ஆபத்துகளைக் குறித்த ஒரு முழுமையான பார்வையும், திட்டமிடுவதற்குத் தேவையான தகவல்களும் கிடைக்கும்.

கேள்வி பதில்களால் முடிவெடுப்பது இன்னொரு வகை. வல்லுநர்களிடம் கேள்வி மேல் கேள்வி கேட்டு எங்கெல்லாம் ஆபத்து வரலாம் என்பதைக் கண்டுபிடிப்பது இந்த வகை. இதில் நாம் யாரிடம் கேள்வி கேட்கிறோம் என்பதை வைத்து வெற்றியும் தோல்வியும் நிர்ணயிக்கப்படும். சரியான நபர்களிடம் நாம் கேள்விகளைக் கேட்டு பதில்களைப் பெற்றால் முழுமையான ஒரு ரிஸ்க் பிளானைப் போட முடியும்.

இப்போது கணினி மயமாக்கப்பட்ட முடிவெடுக்கும் மென்பொருட்களும் பயன்பாட்டில் உள்ளன. தேவையான தகவல்களை உள்ளீடு செய்தால், எந்த ரிஸ்க் எப்படி வரலாம் ? வந்தால் எங்கெங்கே பாதிப்பு வரும், போன்றவற்றையெல்லாம் எளிதில் கண்டறிய முடியும்.

இந்த இடத்தில் ஒரு விஷயத்தை மனதில் கொள்ளுங்கள். என்னென்ன ஆபத்துகள் வரலாம் என கண்டறிந்து “எல்லாவற்றுக்கும்” திட்டம் தீட்டிக்கொண்டிருக்க வேண்டிய அவசியம் இல்லை. எதற்கெல்லாம் திட்டம் தீட்ட வேண்டும், எதையெல்லாம் வரும்போது பார்த்துக் கொள்ளலாம் என்பதையெல்லாம் தீர்மானிக்கின்ற சக்தி புராஜக்ட் மேனேஜர் தான்.

உதாரணமாக ஒரு ஆபத்து வந்தால், அதன் விளைவு அதிகமாக இருக்கும் என்றாலோ அல்லது ஒரு ஆபத்து அடிக்கடி வரும் ஆபத்து உண்டு என்றாலோ அதை எதிர்கொள்ளும் திட்டம் நிச்சயம் தேவை. சில ஆபத்துகள் அதிக பாதிப்புகளை ஏற்படுத்தாது, சில ஆபத்துகள் வரக்கூடிய வாய்ப்புகள் மிக மிகக் குறைவாக இருக்கும். அத்தகைய ஆபத்துகளுக்கான திட்டம் தீட்ட அதிக நேரத்தைச் செலவிடத் தேவையில்லை. எந்த ஆபத்துக்கு திட்டம் தீட்ட வேண்டும், எதை அப்படியே விட்டு விடவேண்டும் என்பதை புராஜக்ட் மேனேஜர் முடிவெடுப்பார். புராஜக்டின் தன்மை, அவரது அனுபவம் போன்றவையெல்லாம் அந்த முடிவை எடுக்க அவருக்கு உதவும்.

சில வேளைகளில் ஆபத்து வரும் வாய்ப்பு குறைவாக இருக்கும், ஆனால் வந்துச்சுன்னா மொத்தம் காலி என்பது போன்ற சூழல் வரும். அத்தகைய ரிஸ்க்களைக் கண்டறிந்து அதற்கான திட்டத்தை நிச்சயம் உருவாக்க வேண்டும். உதாரணமாக மலைப்பகுதியில் ஒரு வீட்டைக் கட்டுவது திட்டமெனில், நிலச்சரிவைப் பற்றி யோசிக்க வேண்டும். வரும் வாய்ப்பு குறைவு தான், ஆனால் வந்தால் எல்லாம் போச்சு எனும் நிலை வரும் இல்லையா ? அது தான் இங்கே கவனிக்கப்பட வேண்டிய விஷயம்.

ரிஸ்க் விஷயத்தில் மூன்று வகைகளைச் சொல்வார்கள்.

1. ரிஸ்கைத் தவிர்ப்பது
2. ரிஸ்கை இன்னொரு இடத்துக்கு அனுப்புவது
3. ரிஸ்கை எதிர்கொள்வது

ரிஸ்கைத் தவிர்ப்பது என்பது எளிதான ஒன்று. எதெல்லாம் ஆபத்தான விஷயமோ அதையெல்லாம் எடுத்துக் கொள்ள வேண்டாம் என்பது. உதாரணமாக, மலைப்பகுதியில் மலைச்சரிவு ஏற்படலாம் எனும் ஆபத்து உண்டெனில், மலைப்பகுதியே வேண்டாம் என முடிவெடுப்பது ரிஸ்கை தவிர்ப்பது. மலைப்பகுதியில் வீடே கட்டவில்லையேல் வீடு சரியாது இல்லையா ?

இரண்டாவது, ரிஸ்கை இடம் மாற்றி விடுவதற்கு உதாரணமாய் இன்சூரன்ஸைச் சொல்லலாம். வீடு ஒருவேளை சரியலாம், உடையலாம் எனும் சூழல் இருந்தால், தொடக்கத்திலேயே நல்ல ஒரு இன்சூரன்ஸ் எடுக்கலாம். ஆபத்து வந்தால் அதை இன்சூரன்ஸ் நிறுவனம் பார்த்துக் கொள்ளும்.

மூன்றாவது, ரிஸ்கை எதிர்கொள்வது. மலைச்சரிவு ஏற்படும் சூழல் உண்டெனில் சரிவிலும் தாக்குப்பிடிக்கும் விதமாகக் கட்டுமானத்தைக் கட்டலாம். அல்லது மிகக்குறைந்த சேதம் வரக்கூடிய அளவுக்கு வரைபடம் வரையலாம். அல்லது என்ன நடந்தாலும் உயிருக்கு ஆபத்து வராதபடி அதை உருவாக்கலாம்.

எது எப்படியெனினும் மிக முக்கியமாய் மனதில் கொள்ள வேண்டிய விஷயம், ரிஸ்க் குறித்து ஆழமான அலசலும், தெளிவான திட்டமிடலும், சிறப்பான ஒரு அணுகுமுறையும் இருக்க வேண்டும் என்பது தான்.

இந்த ரிஸ்க் உலகில் மூன்று வகையான மனநிலை இருக்கவே கூடாது என்பார்கள். ஒன்று, ஆஸ்ட்ரிச் மனநிலை. அதாவது தீக்கோழி மனநிலை. தீக்கோழி என்ன செய்யுமென்பது நமக்குத் தெரியும். எதிரி துரத்திக் கொண்டு வருகிறானெனில் ஓடோ ஓடென்று ஓடி ஒரு இடத்தில் தலையைத் தரையில் புதைத்துக் கொள்ளும். அப்படிச் செய்தால் எதிரிக்குக் கண் தெரியாது என்பது அதன் சிந்தனை. நம்மைத் துரத்துகின்ற சிக்கல்களை கண்ணை மூடிக்கொண்டு அனுமதிக்கும் மனநிலை இது. அப்படி ஒரு பிரச்சினையே இல்லை என மனதை நம்ப வைத்து, தோல்வியடைவது இது. அப்படிப்பட்ட மனநிலை புராஜக்ட் மேனேஜரிடம் இருக்கவே கூடாது.

இரண்டாவது, செப நிலை. பிரேயர் அப்ரோச் என்பார்கள். நம்ம புராஜக்ட்டுக்கு வரக்கூடிய பிரச்சினை எதுவாக இருந்தாலும், விண்ணகத்திலிருந்து ஒருவர் வந்து எல்லாவற்றையும் அழித்து ஒழித்துக் காப்பார் என நம்பும் மனநிலை இது. மந்திர மாயங்களின் மூலம் புராஜக்டின் ரிஸ்க் களை களையவோ, எதிர்கொள்ளவோ முடியாது. அதற்குத் தேவை பிரேயர் அல்ல, பிளானிங்.

மூன்றாவது. சில ரிஸ்க் விஷயங்கள் நமக்குத் தெரிந்திருந்தாலும், அதெல்லாம் நிகழாது என நம்புவது. ஊருக்கெல்லாம் புற்று நோய் வந்தால் கூட, நமக்கு வராது என நம்பி தம்மடிப்பவர்களைப் போல. அந்த ரிஸ்க் சட்டென முகம் காட்டும் போது, வாழ்க்கைக்கு டாட்டா காட்ட வேண்டியது தான்.

ரிஸ்க் பற்றிய ஒரு பொதுவான புரிதல் உங்களுக்குக் கிடைத்திருக்கும் என நம்புகிறேன். இன்னும் விரிவாக எழுதினால் நீங்கள் புக்கை மூடி வைக்கும் ரிஸ்க் உண்டு என்பதால் இப்போதைக்கு முடிக்கிறேன். அடுத்த வாரம் இன்னொரு விஷயம் பற்றிப் பேசுவோம்.

( சேவியர் )

புராஜக்ட் மேனேஜ்மெண்ட் 8 – சவால் & ஆபத்து

8.

சவால்களையும், ஆபத்துகளையும் எதிர்கொள்ளல்

 

ஒருத்தர் நல்ல டிரைவர்ன்னு எப்போ சொல்லுவோம் ? ஆளே இல்லாத ரோட்ல நல்லா வண்டி ஓட்டறவரை நாம நல்ல டிரைவர் ந்னு சொல்றதில்லை. நெருக்கடியான ரோடா இருந்தாலும் லாவகமா, விபத்தை ஏற்படுத்தாம வண்டி ஓட்டறவரைத் தான் நல்ல டிரைவர்ன்னு சொல்லுவோம். அவசரமா ஒரு இடத்துக்குப் போக வேண்டியிருந்தா ரிஸ்க் எடுத்து, அதே நேரம் விபத்து இல்லாம ஓட்டறவரைத் தான் நாம நல்ல டிரைவர்ன்னு சொல்லுவோம் இல்லையா ?

உதாரணமா சென்னை ரோட்டை எடுத்துக்கோங்க. கார் ஓடிட்டே இருக்கும்போ நாலு சைக்கிள் முன்னாடி வரும், அதை சமாளிச்சு அந்தப் பக்கம் போனா ரெண்டு பைக் வரும், அதையும் இடிக்காம முன்னாடி போன ராங் சைட்ல ஒரு மாட்டு வண்டி வரும், பின்னாடி வர வண்டி நம்மை இடிக்காம பிரேக் பிடிக்கும்போ ரெண்டு பேரு சர்வதேச வார்த்தைகளால நம்மை திட்டிட்டே முன்னாடி போவாங்க. இப்படிப்பட்ட ரோட்ல டென்ஷன் இல்லாம, நிதானமா, ஆபத்தில்லாம வண்டி ஓட்டறவர் இருந்தா அவர் தான் நல்ல டிரைவர்.

புராஜக்ட் மேனேஜருக்கு இருக்க வேண்டிய குணாதிசயமும் இது தான். அவரை ஒரு டிரைவரோட ஒப்பிட்டு நாம பேசலாம். இலக்கை போய் சேரணும். விபத்து ஏற்படக் கூடாது. நமக்கும் ஆபத்து நேரக் கூடாது. எந்த ரூட் டிராபிக் அதிகமா இருக்கும்ன்னு கவனிச்சு அதுக்கு ஏற்றபடி போணும். அல்லது மாற்றுப் பாதையை முன் கூட்டியே தீர்மானிக்கணும். யாராச்சும் திட்டினா கூட நிதானம் இழக்கக் கூடாது. இப்படி சொல்லிட்டே போலாம்.

எந்த ஒரு புராஜக்ட்டும் சிவப்புக் கம்பளம் மேல நடக்கிற அனுபவமா இருக்காது. அப்படி இருந்தா அங்கே புராஜக்ட் மேனேஜருக்கு வேலை இல்லை. புராஜக்ட்களெல்லாம் மாமியார் மருமகள் சண்டை மாதிரி சிக்கல்களோடு தான் பயணிக்கும். அதை சமாளிக்கவும், சரியான நேரத்தில், சரியான தீர்மானங்களை எடுக்கவும் புராஜக்ட் மேனேஜர்களுக்கு திறமை தேவைப்படுகிறது. சின்னச் சின்ன புராஜக்ட்கள், குறைந்த நபர்கள் இருக்கின்ற புராஜக்ட்களெல்லாம் பெரிய சிக்கல்களைச் சந்திப்பதில்லை. புராஜக்டின் அளவும், காலமும் அதிகரிக்க அதிகரிக்க சவால்களும் அதிகரித்துக் கொண்டே இருக்கும்.

அதனால் தான் எந்த ஒரு புராஜக்ட்டுக்கும் ‘ரிஸ்க் பிளான்’ அதாவது ‘ஆபத்தை எதிர்கொள்ளும் திட்ட வரைவு’ அவசியமாகிறது. ரிஸ்க் எடுக்கிறது எனக்கு ரஸ்க் சாப்பிடற மாதிரி என நாம் புராஜக்டை ஆரம்பித்தால், கடைசியில் ‘எல்லாத்தையும் பிளான் பண்ணி பண்ணணும்’ என புலம்பி அடங்க வேண்டியிருக்கும்.

ஆபத்து என்பது, நமது புராஜக்டை முடிக்க விடாமல் தடையாய் வருகின்ற விஷயங்கள் எனலாம். ரிஸ்கே இல்லாமல் ஒரு புராஜக்ட் இருக்க வாய்ப்பில்லை. ஆனால் புராஜக்டின் தன்மைக்கு ஏற்ப ரிஸ்கின் அளவு மாறுபடும். உதாரணமாக நீண்ட காலம் செய்ய வேண்டிய புராஜக்ட், திறமையான ஆட்கள் இல்லாத புராஜக்ட், புத்தம் புதிய தொழில்நுட்பத்தில் தொடங்க வேண்டிய புராஜக்ட், முன் அனுபவம் ஏதுமற்ற புதுமையான ஒரு புராஜக்ட் இவற்றுக்கெல்லாம் ரிஸ்க் கொஞ்சம் அதிகம். அதை அலசி ஆராய்ந்து திட்டமிட வேண்டும்.

இரண்டு விதமான ரிஸ்க் உண்டு. ஒன்று நெகடிவ் ரிஸ்க். இன்னொன்று பாசிடிவ் ரிஸ்க். நெகடிவ் என்றாலே பெயரைப் போலவே எதிர்மறையான ஒரு விளைவை உருவாக்குவது என புரிந்து கொள்ளலாம். ஏதோ ஒரு விஷயம், புராஜக்டை சரியான நேரத்தில் முடிக்க விடாமல் செய்கிறது. அல்லது ஒரு விஷயம் நல்ல தரத்தில் புராஜக்டை செய்ய விடாமல் தடுக்கிறது. இவையெல்லாம் எதிர்மறை ஆபத்துகள்.

பாசிடிவ் ரிஸ்க் எனப்படும் நேர்மறை ஆபத்துகளை, ஆபத்துகள் என்று சொல்வதே தவறு தான். அதாவது புராஜக்ட் நிர்ணயிக்கப்பட்ட நாளில் முடியாது. ஆனால் அதற்கு முன்பாகவே முடிந்து விடும் என்பது நேர்மறை ஆபத்தின் உதாரணம். அல்லது பத்து கோடி பட்ஜெட் போட்டது, எட்டு கோடியில் முடிந்து விடுவதைப் போன்ற ஆனந்தப் பிழை இது.

சரி, இந்த ரிஸ்க் மேனேஜ்மென்ட் என்பது எதிர்மறை ரிஸ்கைத் தான் முக்கியமாகக் கவனிக்கும். ஆபத்து மேலாண்மை இருப்பதனால் ஆபத்து வராது என்று அர்த்தமல்ல, ஆனால் அப்படி வரும்போது என்ன செய்யலாம் என்பதற்கான முன்னேற்பாடுகள் செய்யப்பட்டிருக்கும். அல்லது என்ன செய்ய வேண்டும் என்பது திட்டமிடப்பட்டிருக்கும்.

உதாரணமாக மழைக்கால மீட்புக் குழுவை மனதில் நினையுங்கள். அப்படி ஒரு குழு இருக்கிறது என்பதற்காக மழை வராது என்று அர்த்தமல்ல. மழை வந்தால் என்ன செய்ய வேண்டும். வெள்ளப்பெருக்கு வந்தால் என்ன செய்யவேண்டும் போன்ற திட்டங்கள் தயாராய் இருக்கும். அதனால் திடீரென வெள்ளம் வரும்போது பதற வேண்டியிருக்காது.

இந்த ரிஸ்க் மேஜேன்மென்டில் ஐந்து நிலைகள் உண்டு.

1. ரிஸ்கைக் கண்டறிதல்

புராஜக்டின் பாதையில் என்னென்ன ஆபத்துகள் வரலாம் என்பதைக் கணிப்பது. முன் அனுபவங்களும், புராஜக்டின் தன்மையை நன்றாகப் புரிந்து வைத்திருப்பதும் இந்த ஆபத்துகளைக் கண்டறியும் பணியில் கைகொடுக்கும்.

2. ரிஸ்கின் விளைவுகளை புரிந்து கொள்ளுதல்.

கண்டறிந்த ஆபத்துகள் உண்மையிலேயே நிகழ்ந்தால் என்னென்ன பாதிப்புகள் வரும் என்பதைப் பட்டியலிடுதல். வேலை செய்ய சரியான ஆட்கள் கிடைக்கவில்லையேல் என்ன செய்வது ? அப்படிப்பட்ட சூழலில் என்ன ஆபத்து வரலாம் ? இவற்றையெல்லாம் கண்டறிவது இரண்டாம் நிலை.

3. ரிஸ்கை எதிர்கொள்ளத் திட்டமிடுதல்.

சரி, ரிஸ்க் வரலாம். அப்படி வந்தால் இந்த பிரச்சினை நேரலாம். அப்படியானால் அதை எதிர்கொள்ள என்னென்ன திட்டம் இடவேண்டும் என்பதைப் பற்றிய நிலை இது. மிக முக்கியமான கட்டம்.

4. ரிஸ்கைக் கண்காணித்தல்.

ஒரு ரிஸ்க் வந்தாச்சு என்றால் அதைக் கவனிப்பது, அது குறைகிறதா அதிகரிக்கிறதா என்பதைப் பார்ப்பது, இந்த ரிஸ்க் வேறு ரிஸ்க் களைக் கொண்டு வருமா என யோசிப்பது இவையெல்லாம் இந்த நிலையில் வரும்.

5. ரிஸ்கை அறிவித்தல்.

ஆபத்து இருப்பதை சம்பந்தப்பட்ட எல்லாருக்கும் அறிவிப்பது இந்த நிலை. புராஜக்டின் தொடக்கம் முதல் முடிவு வரை ஒவ்வொரு கட்டத்திலும் இந்த ஆபத்துகளைக் கண்டறிவதும், அறிவிப்பதும் மிகவும் முக்கியம்.

ஊர்ல உள்ள பெரியவர்களிடம் இப்படியெல்லாம் பேசினால், “ஏண்டா வெறுத்த வாக்கு பேசறே. நல்லதா பேசேன்பா” என்பார்கள். புராஜக்டைப் பொறுத்தவரை நெகடிவ் சிந்தனை ரொம்ப முக்கியம். ஐயோ ஆபத்து வரலாம் எனும் சிந்தனை தான் வண்டி ஓட்டும்போது சீட்பெல்ட் போட நம்மைத் தூண்டுகிறது. போலீஸ்காரர்கள் நிறுத்துவார்கள் எனும் பயம் தான் ஹெல்மெட்டை போட நினைவூட்டுகிறது. விபத்து ஏற்பட்டா என்ன செய்றது எனும் அச்சம் தான் இன்சூரன்ஸ் எடுக்க நம்மை வலியுறுத்துகிறது. எனவே தான் இந்த நெகடிவ் சிந்தனை புராஜக்ட்டில் ரொம்ப முக்கியமாகிறது.

காட்ஃபாதர் திரைப்படத்தில் ஒரு வசனம் வரும், “நல்லது நடக்கும் என நம்பு. ரொம்ப மோசமாக நடந்தால் என்ன செய்வது என திட்டமிடு” என்று. அதை அப்படியே அலேக்காகத் தூக்கி இந்த புராஜக்ட் மேனேஜ்மென்டில் பொருத்திக் கொள்ளலாம்.

உதாரணமாக புராஜக்டில் ஒரு நல்ல சுறுசுறுப்பான கில்லாடி வேலைக்காரர் இருக்கிறார் என வைத்துக் கொள்வோம். அவர் தான் புராஜக்டின் முதுகெலும்பு. நமது புராஜக்ட் முடியும் வரை அவர் நம்மோடு இருப்பார் என நம்ப வேண்டும். அதே நேரம், அவர் சட்டென ஒரு நாள் வேலையை விட்டு நின்று விட்டால், என்ன செய்வது எனும் திட்டம் தயாராய் இருக்க வேண்டும். பேக் அப் பிளான் எனப்படும், மாற்று வழி தயாராய் இருக்க வேண்டும். அது தான் விஷயம்.

ஒரு விஷயத்தை மனதில் கொள்ளுங்கள். ரிஸ்க் பிளான் என்பது கண்டிப்பாக அந்த ஆபத்து வரும் என‌ அடித்துச் சொல்கிற சமாச்சாரம் அல்ல. அந்த ஆபத்து வருவதற்கான வாய்ப்புகள் அதிகம் என்பதை பதிவு செய்வது தான்.

ரிஸ்க் குறித்து இன்னும் கொஞ்சம் விரிவாய்ப் பார்ப்பது பயனளிக்கும் என நினைக்கிறேன். அடுத்த வாரம் இன்னும் கொஞ்சம் விஷயங்களைப் பற்றிப் பேசுவோம்

( தொடரும் )