OD ਅਤੇ ਟੈਲੰਟ ਪਲੇਟਫ਼ਾਰਮ ਦਾ ਬਿਜ਼ਨਸ ਕੇਸ: ਸਾਫ਼ਟਵੇਅਰ ਨਹੀਂ, ਫ਼ੈਸਲਾ ਵੇਚੋ

ਸੰਗਠਨ ਵਿਕਾਸ ਅਤੇ ਟੈਲੰਟ ਸਾਫ਼ਟਵੇਅਰ ਲਈ ਜ਼ਿਆਦਾਤਰ ਬਿਜ਼ਨਸ ਕੇਸ ਮੀਟਿੰਗ ਦੇ ਪਹਿਲੇ ਦਸ ਮਿੰਟਾਂ ਵਿੱਚ ਹਾਰ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਇੱਕੋ ਕਾਰਨ ਕਰਕੇ। ਉਹ ਸਾਫ਼ਟਵੇਅਰ ਬਿਆਨ ਕਰਦੇ ਹਨ: ਫ਼ੀਚਰ, ਮੋਡਿਊਲ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਹਰ ਮੈਨੇਜਰ ਦੇ ਬਚੇ ਘੰਟੇ। ਸੀਨੀਅਰ ਲੀਡਰਸ਼ਿਪ ਨੂੰ ਇੱਕ ਨਵੀਂ ਲਾਗਤ ਸੁਣਦੀ ਹੈ ਜਿਸ ਦੇ ਫ਼ਾਇਦੇ ਨਰਮ ਲੱਗਦੇ ਹਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਆਉਂਦੇ ਹਨ। ਜੋ ਕੇਸ ਮਨਜ਼ੂਰ ਹੁੰਦੇ ਹਨ ਉਹ ਉਲਟੇ ਢੰਗ ਨਾਲ ਬਣੇ ਹੁੰਦੇ ਹਨ। ਉਹ ਇੱਕ ਮਹਿੰਗੀ, ਵਾਰ-ਵਾਰ ਆਉਂਦੀ ਸੰਗਠਨਾਤਮਕ ਸਮੱਸਿਆ ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ ਜੋ ਲੀਡਰਸ਼ਿਪ ਪਹਿਲਾਂ ਹੀ ਮਹਿਸੂਸ ਕਰਦੀ ਹੈ, ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਉਸ ਸਮੱਸਿਆ ਦੀ ਕੀ ਲਾਗਤ ਹੈ, ਅਤੇ ਪਲੇਟਫ਼ਾਰਮ ਨੂੰ ਉਸ ਲਾਗਤ ਨੂੰ ਰੋਕਣ ਦੇ ਸਭ ਤੋਂ ਸਸਤੇ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਵਜੋਂ ਪੇਸ਼ ਕਰਦੇ ਹਨ। ਅਤੇ ਉਹ ਬਜਟ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਪਾਇਲਟ ਮੰਗਦੇ ਹਨ।

ਅਸੀਂ ਇਸ ਗੱਲਬਾਤ ਦੇ ਦੋਵੇਂ ਪਾਸੇ ਰਹੇ ਹਾਂ, HR ਅਤੇ ਰਣਨੀਤੀ ਦੇ ਆਗੂਆਂ ਨੂੰ ਕੇਸ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਿਆਂ ਅਤੇ ਉਨ੍ਹਾਂ 'ਤੇ ਫ਼ੈਸਲਾ ਕਰਨ ਵਾਲੀਆਂ ਲੀਡਰਸ਼ਿਪ ਟੀਮਾਂ ਦੇ ਸਾਹਮਣੇ ਬੈਠਦਿਆਂ। ਇੱਕ ਅਸੁਖਾਵੀਂ ਸਲਾਹ ਅਸੀਂ ਹਰ ਵਾਰ ਦਿੰਦੇ ਹਾਂ: ਜੇ ਤੁਸੀਂ ਉਸ ਫ਼ੈਸਲੇ ਦਾ ਨਾਂ ਨਹੀਂ ਲੈ ਸਕਦੇ ਜੋ ਪਲੇਟਫ਼ਾਰਮ ਬਦਲੇਗਾ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਨਹੀਂ ਖ਼ਰੀਦਣਾ ਚਾਹੀਦਾ। ਇਸ ਵਿੱਚ ਸਾਡਾ ਪਲੇਟਫ਼ਾਰਮ ਖ਼ਰੀਦਣਾ ਵੀ ਸ਼ਾਮਲ ਹੈ।

«ਤੁਸੀਂ ਮੈਨੂੰ ਇਹ ਦੱਸਿਆ ਕਿ ਇਹ ਕੀ ਕਰਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਕੀ ਬਦਲੇਗਾ»

ਸਾਊਦੀ ਅਰਬ ਦੀ ਲਗਭਗ ਤਿੰਨ ਸੌ ਮੁਲਾਜ਼ਮਾਂ ਵਾਲੀ ਇੱਕ ਕੰਪਨੀ ਦੇ HR ਡਾਇਰੈਕਟਰ ਨੇ ਇੱਕ ਟੈਲੰਟ ਅਤੇ ਸੰਗਠਨ ਵਿਕਾਸ ਪਲੇਟਫ਼ਾਰਮ ਲਈ ਬਿਜ਼ਨਸ ਕੇਸ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਕਈ ਹਫ਼ਤੇ ਲਾਏ। ਇਹ ਤੀਹ ਸਲਾਈਡਾਂ ਦਾ ਸੀ: ਚਾਰ ਵਿਕਰੇਤਾਵਾਂ ਦੇ ਫ਼ੀਚਰਾਂ ਦੀ ਤੁਲਨਾ, ਕਾਰਗੁਜ਼ਾਰੀ ਸਮੀਖਿਆਵਾਂ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਵਿੱਚ ਬਚੇ ਘੰਟਿਆਂ ਦਾ ਅੰਦਾਜ਼ਾ, ਅਤੇ ਵਿਕਰੇਤਾ ਦੇ ਅੰਕੜਿਆਂ ਤੋਂ ਬਣਿਆ ਨਿਵੇਸ਼ 'ਤੇ ਰਿਟਰਨ ਦਾ ਹਿਸਾਬ।

ਚੀਫ਼ ਫ਼ਾਈਨੈਂਸ਼ਲ ਅਫ਼ਸਰ ਨੇ ਲਗਭਗ ਦਸ ਮਿੰਟਾਂ ਵਿੱਚ ਇਸ ਨੂੰ ਨਾਮਨਜ਼ੂਰ ਕਰ ਦਿੱਤਾ। HR ਡਾਇਰੈਕਟਰ ਨੂੰ ਜੋ ਗੱਲ ਯਾਦ ਰਹਿ ਗਈ ਉਹ ਕਾਰਨ ਸੀ: «ਤੁਸੀਂ ਮੈਨੂੰ ਇਹ ਦੱਸਿਆ ਕਿ ਇਹ ਕੀ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਦੱਸਿਆ ਕਿ ਕੀ ਬਦਲੇਗਾ, ਜਾਂ ਕੌਣ ਬਦਲੇਗਾ।»

ਦੂਜੀ ਕੋਸ਼ਿਸ਼ ਇੱਕ ਸਲਾਈਡ ਦੀ ਸੀ। ਕੁਝ ਮਹੀਨੇ ਪਹਿਲਾਂ ਲੀਡਰਸ਼ਿਪ ਆਫ਼ਸਾਈਟ ਵਿੱਚ ਸੀਈਓ ਨੇ ਸ਼ਿਕਾਇਤ ਕੀਤੀ ਸੀ ਕਿ ਸਾਲ ਦੀਆਂ ਤਿੰਨ ਰਣਨੀਤਕ ਪਹਿਲਕਦਮੀਆਂ ਰੁਕ ਗਈਆਂ ਹਨ, ਅਤੇ ਕੋਈ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਉਨ੍ਹਾਂ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ। ਨਵੇਂ ਕੇਸ ਨੇ ਉਸ ਸਮੱਸਿਆ ਦਾ ਨਾਂ ਲਿਆ, ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਪਹਿਲਕਦਮੀ ਤੋਂ ਦੇਰੀ ਨਾਲ ਆਉਣ ਵਾਲੀ ਆਮਦਨ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਇਆ, ਨੱਬੇ ਦਿਨਾਂ ਦਾ ਪਾਇਲਟ ਤਜਵੀਜ਼ ਕੀਤਾ ਜਿਸ ਵਿੱਚ ਲੀਡਰਸ਼ਿਪ ਟੀਮ ਪਲੇਟਫ਼ਾਰਮ ਵਰਤ ਕੇ ਉਨ੍ਹਾਂ ਤਿੰਨ ਪਹਿਲਕਦਮੀਆਂ ਦੀ ਮਾਲਕੀ ਸੌਂਪੇਗੀ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਟਰੈਕ ਕਰੇਗੀ, ਅਤੇ ਪੈਸਾ ਸਿਰਫ਼ ਤਾਂ ਮੰਗਿਆ ਜੇ ਪਾਇਲਟ ਪਹਿਲਾਂ ਤੋਂ ਤੈਅ ਮਾਪ 'ਤੇ ਪੂਰਾ ਉਤਰੇ। ਇਹ ਉਸੇ ਮੀਟਿੰਗ ਵਿੱਚ ਮਨਜ਼ੂਰ ਹੋ ਗਿਆ।

ਇੱਕ-ਫ਼ੈਸਲੇ ਵਾਲਾ ਬਿਜ਼ਨਸ ਕੇਸ

ਦੂਜੀ ਕੋਸ਼ਿਸ਼ ਪਿੱਛੇ ਦੇ ਢਾਂਚੇ ਦੇ ਪੰਜ ਹਿੱਸੇ ਹਨ, ਅਤੇ ਇਹ ਲਗਭਗ ਕਿਸੇ ਵੀ ਸੰਗਠਨਾਤਮਕ ਨਿਵੇਸ਼ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ, ਸਿਰਫ਼ ਸਾਫ਼ਟਵੇਅਰ ਲਈ ਨਹੀਂ।

1. ਸਮੱਸਿਆ। ਇੱਕ ਨਾਂ ਸਮੇਤ, ਵਾਰ-ਵਾਰ ਆਉਂਦੀ, ਮਹਿੰਗੀ ਸੰਗਠਨਾਤਮਕ ਸਮੱਸਿਆ ਜਿਸ ਨੂੰ ਲੀਡਰਸ਼ਿਪ ਪਹਿਲਾਂ ਹੀ ਮਹਿਸੂਸ ਕਰ ਚੁੱਕੀ ਹੈ, ਬਿਹਤਰ ਹੋਵੇ ਤਾਂ ਉਨ੍ਹਾਂ ਦੇ ਆਪਣੇ ਸ਼ਬਦਾਂ ਵਿੱਚ। ਰੁਕੀਆਂ ਪਹਿਲਕਦਮੀਆਂ, ਅਸਪੱਸ਼ਟ ਫ਼ੈਸਲਾ-ਅਧਿਕਾਰ, ਕਿਸੇ ਅਹਿਮ ਟੀਮ ਵਿੱਚੋਂ ਅਜਿਹੇ ਲੋਕਾਂ ਦਾ ਜਾਣਾ ਜਿਨ੍ਹਾਂ ਦਾ ਅਫ਼ਸੋਸ ਹੈ, ਇੱਕ ਪੁਨਰਗਠਨ ਜੋ ਟਿਕਿਆ ਨਹੀਂ। ਜੇ ਲੀਡਰਸ਼ਿਪ ਪਹਿਲਾਂ ਹੀ ਨਹੀਂ ਮੰਨਦੀ ਕਿ ਸਮੱਸਿਆ ਮੌਜੂਦ ਹੈ, ਤਾਂ ਕੋਈ ਬਿਜ਼ਨਸ ਕੇਸ ਉਨ੍ਹਾਂ ਨੂੰ ਯਕੀਨ ਨਹੀਂ ਦਿਵਾਏਗਾ; ਸ਼ੁਰੂਆਤ ਉੱਥੋਂ ਕਰੋ।
2. ਕੁਝ ਨਾ ਕਰਨ ਦੀ ਲਾਗਤ। ਜੇ ਸਮੱਸਿਆ ਜਾਰੀ ਰਹੇ ਤਾਂ ਉਸ ਦੀ ਕੀ ਲਾਗਤ ਹੈ, ਇਸ ਦਾ ਦਾਇਰਿਆਂ ਵਿੱਚ ਅੰਦਾਜ਼ਾ, ਉਨ੍ਹਾਂ ਸ਼ਬਦਾਂ ਵਿੱਚ ਜੋ ਲੀਡਰਸ਼ਿਪ ਪਹਿਲਾਂ ਹੀ ਵਰਤਦੀ ਹੈ: ਦੇਰੀ ਨਾਲ ਆਈ ਆਮਦਨ, ਗੁਆਏ ਇਕਰਾਰਨਾਮੇ, ਬਦਲੀ ਦੀਆਂ ਲਾਗਤਾਂ, ਉੱਪਰ ਭੇਜੇ ਮਾਮਲਿਆਂ 'ਤੇ ਲੱਗਾ ਮੈਨੇਜਮੈਂਟ ਦਾ ਸਮਾਂ। ਸੰਜਮੀ ਅਤੇ ਭਰੋਸੇਯੋਗ ਅੰਕੜਾ ਵੱਡੇ ਅਤੇ ਵਿਵਾਦਿਤ ਅੰਕੜੇ ਤੋਂ ਬਿਹਤਰ ਹੈ।
3. ਤਬਦੀਲੀ। ਕਿਹੜਾ ਫ਼ੈਸਲਾ ਜਾਂ ਵਿਹਾਰ ਵੱਖਰਾ ਹੋਵੇਗਾ, ਅਤੇ ਕੌਣ ਉਸ ਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਕਰੇਗਾ। ਇਹ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਕੇਸ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਇਹੀ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਕਹਾਣੀ ਵਾਲਾ CFO ਮੰਗ ਰਿਹਾ ਸੀ। ਸਾਫ਼ਟਵੇਅਰ ਆਪਣੇ-ਆਪ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ; ਉਸ ਨੂੰ ਵਰਤ ਕੇ ਵੱਖਰੇ ਫ਼ੈਸਲੇ ਲੈਣ ਵਾਲੇ ਲੋਕ ਬਦਲਦੇ ਹਨ।
4. ਸਬੂਤ। ਅਸਲ ਸਮੱਸਿਆ 'ਤੇ ਇੱਕ ਛੋਟਾ, ਸਮੇਂ ਦੀ ਹੱਦ ਵਾਲਾ ਪਾਇਲਟ, ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਨਾਲ ਜਿਨ੍ਹਾਂ ਦੇ ਫ਼ੈਸਲੇ ਬਦਲਣੇ ਹਨ, ਅਤੇ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਇੱਕ ਮਾਪ।
5. ਮੰਗ। ਪਾਇਲਟ ਦੇ ਨਤੀਜੇ ਨਾਲ ਜੁੜੀ ਪੜਾਅਵਾਰ ਵਚਨਬੱਧਤਾ, ਅੰਦਰੂਨੀ ਸਮੇਂ ਸਮੇਤ ਪੂਰੀ ਲਾਗਤ ਦੱਸ ਕੇ, ਅਤੇ ਜੇ ਇਹ ਕੰਮ ਨਾ ਕਰੇ ਤਾਂ ਰੁਕਣ ਦਾ ਸਾਫ਼ ਰਾਹ।

ਇਸ ਤਰ੍ਹਾਂ ਬਣਿਆ ਕੇਸ ਅਕਸਰ ਇੱਕ ਸਫ਼ੇ ਤੋਂ ਵੀ ਛੋਟਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਕਮਜ਼ੋਰੀ ਨਹੀਂ; ਇਹੀ ਇਸ ਨੂੰ ਅਜਿਹੀ ਲੀਡਰਸ਼ਿਪ ਟੀਮ ਲਈ ਪੜ੍ਹਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ ਜਿਸ ਨੇ ਉਸ ਮਹੀਨੇ ਚਾਲੀ ਹੋਰ ਫ਼ੈਸਲੇ ਲੈਣੇ ਹਨ।

ਅਤੇ ਇਹ ਰਹੀ ਉਲਟ ਗੱਲ

ROI ਦੀ ਪ੍ਰਤੀਸ਼ਤ ਨਾਲ ਸ਼ੁਰੂਆਤ ਨਾ ਕਰੋ। ਸਾਫ਼ਟਵੇਅਰ ਦੇ ਬਿਜ਼ਨਸ ਕੇਸ ਦਾ ਇਹ ਉਹ ਹਿੱਸਾ ਹੈ ਜਿਸ 'ਤੇ ਲੀਡਰਸ਼ਿਪ ਸਭ ਤੋਂ ਘੱਟ ਭਰੋਸਾ ਕਰਦੀ ਹੈ, ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਪਤਾ ਹੈ ਕਿ ਇਹ ਵਿਕਰੇਤਾ ਤੋਂ ਆਇਆ ਹੈ, ਅਤੇ ਇਹ ਗੱਲਬਾਤ ਨੂੰ ਸਮੱਸਿਆ ਤੋਂ ਹਟਾ ਕੇ ਅੰਕੜੇ ਪਿਛਲੀਆਂ ਧਾਰਨਾਵਾਂ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ। ਜਿਸ ਲਾਗਤ 'ਤੇ ਲੀਡਰਸ਼ਿਪ ਪਹਿਲਾਂ ਹੀ ਯਕੀਨ ਕਰਦੀ ਹੈ ਉਸ ਦਾ ਨਿਮਰ ਅੰਦਾਜ਼ਾ ਉਸ ਵੱਡੇ ਰਿਟਰਨ ਨਾਲੋਂ ਕਿਤੇ ਵੱਧ ਯਕੀਨ ਦਿਵਾਉਂਦਾ ਹੈ ਜਿਸ ਨੂੰ ਉਨ੍ਹਾਂ ਨੂੰ ਅੱਖਾਂ ਮੀਟ ਕੇ ਮੰਨਣਾ ਪਵੇ।

ਜਿੰਨੀ ਲੋੜ ਹੈ ਉਸ ਤੋਂ ਘੱਟ ਮੰਗੋ। ਪਾਇਲਟ ਵਾਲੀ ਪੜਾਅਵਾਰ ਵਚਨਬੱਧਤਾ ਵੱਡੇ ਸਾਲਾਨਾ ਇਕਰਾਰਨਾਮੇ ਨਾਲੋਂ ਮਨਜ਼ੂਰ ਕਰਨੀ ਸੌਖੀ ਹੈ, ਅਤੇ ਇਹ ਲੀਡਰਸ਼ਿਪ ਵੱਲੋਂ ਜਵਾਬ ਦਿੱਤੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ ਨੂੰ «ਕੀ ਇਹ ਪੈਸੇ ਦੇ ਲਾਇਕ ਹੈ?» ਤੋਂ ਬਦਲ ਕੇ «ਕੀ ਇਹ ਨੱਬੇ ਦਿਨਾਂ ਦੇ ਲਾਇਕ ਹੈ?» ਕਰ ਦਿੰਦੀ ਹੈ। ਜੇ ਪਾਇਲਟ ਕੰਮ ਕਰ ਜਾਵੇ, ਤਾਂ ਦੂਜੀ ਮਨਜ਼ੂਰੀ ਉਸ ਨਾਲੋਂ ਕਿਤੇ ਸੌਖੀ ਹੁੰਦੀ ਹੈ ਜਿੰਨੀ ਪਹਿਲੀ ਹੁੰਦੀ।

ਲੁਕੀਆਂ ਲਾਗਤਾਂ ਆਪ ਸ਼ਾਮਲ ਕਰੋ। ਕਿਸੇ ਸੰਗਠਨਾਤਮਕ ਪਲੇਟਫ਼ਾਰਮ ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਲਾਗਤ ਘੱਟ ਹੀ ਲਾਇਸੈਂਸ ਹੁੰਦੀ ਹੈ। ਉਹ ਲੀਡਰਸ਼ਿਪ ਦਾ ਸਮਾਂ ਹੁੰਦਾ ਹੈ, ਫਿਰ ਢਾਂਚੇ ਅਤੇ ਭੂਮਿਕਾਵਾਂ ਦਾ ਮੌਜੂਦਾ ਡਾਟਾ ਤਿਆਰ ਕਰਨ ਦਾ ਕੰਮ ਅਤੇ ਲੋਕਾਂ ਵੱਲੋਂ ਇਸ ਨੂੰ ਸੱਚਮੁੱਚ ਵਰਤਣ ਲਈ ਲੋੜੀਂਦੀ ਤਬਦੀਲੀ। ਜੋ ਬਿਜ਼ਨਸ ਕੇਸ ਇਨ੍ਹਾਂ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਉਹ ਵੱਧ ਯਕੀਨ ਨਹੀਂ ਦਿਵਾਉਂਦੇ। ਲੀਡਰਸ਼ਿਪ ਇਨ੍ਹਾਂ ਬਾਰੇ ਉਂਝ ਵੀ ਸੋਚਦੀ ਹੈ, ਅਤੇ ਇਹ ਛੋਟ ਲੇਖਕ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਮਹਿੰਗੀ ਪੈਂਦੀ ਹੈ।

ਇਹ ਕੰਮ ਕਿਉਂ ਕਰਦਾ ਹੈ

ਇਸ ਦੇ ਕਾਰਨ ਫ਼ੈਸਲਿਆਂ ਦੀ ਖੋਜ ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਦਰਜ ਹਨ। Samuelson ਅਤੇ Zeckhauser ਨੇ 1980 ਦੇ ਦਹਾਕੇ ਦੇ ਅਖ਼ੀਰ ਵਿੱਚ status quo bias ਬਿਆਨ ਕੀਤਾ: ਜਦੋਂ ਲੋਕ ਮੌਜੂਦਾ ਹਾਲਤ ਰੱਖਣ ਅਤੇ ਉਸ ਨੂੰ ਬਦਲਣ ਵਿਚਕਾਰ ਚੁਣਦੇ ਹਨ, ਤਾਂ ਉਹ ਮੌਜੂਦਾ ਹਾਲਤ ਨੂੰ ਉਸ ਦੀ ਯੋਗਤਾ ਤੋਂ ਵੱਧ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ। ਇਸ ਲਈ ਬਿਜ਼ਨਸ ਕੇਸ ਨੂੰ ਮੌਜੂਦਾ ਹਾਲਤ ਨੂੰ ਇੱਕ ਨਿਰਪੱਖ ਮੂਲ ਸਥਿਤੀ ਵਜੋਂ ਨਹੀਂ, ਸਗੋਂ ਆਪਣੀਆਂ ਲਾਗਤਾਂ ਵਾਲੀ ਇੱਕ ਚੋਣ ਵਜੋਂ ਦਿਖਾਉਣਾ ਪੈਂਦਾ ਹੈ। ਕੁਝ ਨਾ ਕਰਨ ਦੀ ਲਾਗਤ ਵਾਲਾ ਹਿੱਸਾ ਇਹੀ ਕਰਦਾ ਹੈ।

Kahneman ਅਤੇ Tversky ਦੀ prospect theory ਸਮਝਾਉਂਦੀ ਹੈ ਕਿ ਸਮੱਗਰੀ ਦੇ ਨਾਲ-ਨਾਲ ਪੇਸ਼ਕਾਰੀ ਦਾ ਢੰਗ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ। ਨੁਕਸਾਨ ਬਰਾਬਰ ਦੇ ਫ਼ਾਇਦਿਆਂ ਨਾਲੋਂ ਵੱਡੇ ਲੱਗਦੇ ਹਨ, ਇਸ ਲਈ ਜਿਸ ਸਮੱਸਿਆ ਦੀ ਕੀਮਤ ਲੀਡਰਸ਼ਿਪ ਪਹਿਲਾਂ ਹੀ ਚੁਕਾ ਰਹੀ ਹੈ ਉਸ ਨੂੰ ਉਸ ਫ਼ਾਇਦੇ ਨਾਲੋਂ ਵੱਧ ਭਾਰ ਮਿਲਦਾ ਹੈ ਜੋ ਸ਼ਾਇਦ ਮਿਲ ਜਾਵੇ। John Kotter ਨੇ Leading Change ਵਿੱਚ ਇਹੀ ਗੱਲ ਸੰਗਠਨਾਤਮਕ ਸ਼ਬਦਾਂ ਵਿੱਚ ਕਹੀ: ਕਿਸੇ ਵੀ ਤਬਦੀਲੀ ਦਾ ਪਹਿਲਾ ਕਦਮ ਜ਼ਰੂਰਤ ਦਾ ਅਹਿਸਾਸ ਪੈਦਾ ਕਰਨਾ ਹੈ, ਅਤੇ ਜਿਸ ਬਿਜ਼ਨਸ ਕੇਸ ਨੂੰ ਇਹ ਅਹਿਸਾਸ ਸਿਫ਼ਰ ਤੋਂ ਪੈਦਾ ਕਰਨਾ ਪਵੇ ਉਹ ਚੜ੍ਹਾਈ ਚੜ੍ਹ ਰਿਹਾ ਹੁੰਦਾ ਹੈ।

ਅਖ਼ੀਰ ਵਿੱਚ, ਇਹ ਉਸ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜੋ ਅਸੀਂ ਉਨ੍ਹਾਂ ਸੰਗਠਨਾਂ ਵਿੱਚ ਵੇਖਦੇ ਹਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਜਿਹੇ ਪਲੇਟਫ਼ਾਰਮਾਂ ਤੋਂ ਮੁੱਲ ਮਿਲਦਾ ਹੈ। ਮੁੱਲ ਲਗਭਗ ਕਦੇ ਵੀ ਇਕੱਲੇ ਸਾਫ਼ਟਵੇਅਰ ਤੋਂ ਨਹੀਂ ਆਉਂਦਾ; ਇਹ ਇੱਕ ਲੀਡਰਸ਼ਿਪ ਟੀਮ ਦੇ ਵੱਖਰੇ ਫ਼ੈਸਲੇ ਲੈਣ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਜਿਸ ਢਾਂਚੇ, ਮਾਲਕੀ ਅਤੇ ਮਾਪਾਂ ਦੀ ਉਨ੍ਹਾਂ ਨੂੰ ਲੋੜ ਹੈ ਉਹ ਆਖ਼ਰਕਾਰ ਇੱਕੋ ਥਾਂ ਦਿਸਦੇ ਹਨ। ਰਣਨੀਤੀ ਦਾ ਅਮਲ ਕਿਉਂ ਅਸਫਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਫ਼ੈਸਲਿਆਂ ਦਾ ਵਹਾਅ ਬਾਰੇ ਸਾਡੇ ਲੇਖ ਉਨ੍ਹਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਬਿਆਨ ਕਰਦੇ ਹਨ ਜੋ ਉਸ ਦਿੱਖ ਦਾ ਮੁੱਲ ਚੁਕਾਉਣ ਲਾਇਕ ਬਣਾਉਂਦੀਆਂ ਹਨ।

ਇੱਕ ਵਿਹਾਰਕ ਸੂਚੀ

• ਸਮੱਸਿਆ ਨੂੰ ਲੀਡਰਸ਼ਿਪ ਦੇ ਆਪਣੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਲੱਭੋ: ਆਫ਼ਸਾਈਟ ਦੇ ਨੋਟ, ਬੋਰਡ ਦੀਆਂ ਚਰਚਾਵਾਂ, ਉਹ ਸ਼ਿਕਾਇਤ ਜੋ ਸੀਈਓ ਵਾਰ-ਵਾਰ ਦੁਹਰਾਉਂਦਾ ਹੈ।
• ਸਮੱਸਿਆ ਦੇ ਇੱਕ ਮਾਮਲੇ ਦੀ ਲਾਗਤ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਓ, ਸੰਜਮ ਨਾਲ ਅਤੇ ਦਾਇਰਿਆਂ ਵਿੱਚ, HR ਦੀ ਥਾਂ ਕਾਰੋਬਾਰ ਦੇ ਸ਼ਬਦਾਂ ਵਿੱਚ।
• ਇੱਕ ਵਾਕ ਲਿਖੋ ਕਿ ਕੀ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਤੈਅ ਹੋਵੇਗਾ ਅਤੇ ਕਿਸ ਵੱਲੋਂ। ਜੇ ਨਹੀਂ ਲਿਖ ਸਕਦੇ, ਤਾਂ ਰੁਕੋ ਅਤੇ ਖ਼ਰੀਦ 'ਤੇ ਮੁੜ ਵਿਚਾਰ ਕਰੋ।
• ਅਸਲ ਸਮੱਸਿਆ 'ਤੇ ਪਾਇਲਟ ਡਿਜ਼ਾਈਨ ਕਰੋ, ਸਮੇਂ ਦੀ ਹੱਦ ਵਾਲਾ, ਫ਼ੈਸਲਾ ਲੈਣ ਵਾਲਿਆਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਕੇ ਅਤੇ ਪਹਿਲਾਂ ਤੋਂ ਤੈਅ ਮਾਪ ਸਮੇਤ।
• ਪੂਰੀ ਲਾਗਤ ਸੂਚੀਬੱਧ ਕਰੋ, ਲੀਡਰਸ਼ਿਪ ਦਾ ਸਮਾਂ, ਡਾਟਾ ਦੀ ਤਿਆਰੀ, ਕਨਫ਼ਿਗਰੇਸ਼ਨ, ਸਿਖਲਾਈ ਅਤੇ ਪਰਿਵਰਤਨ ਦੀ ਸਹਾਇਤਾ ਸਮੇਤ।
• ਪੜਾਅਵਾਰ ਵਚਨਬੱਧਤਾ ਮੰਗੋ ਜੋ ਪਾਇਲਟ ਦੇ ਨਤੀਜੇ ਨਾਲ ਜੁੜੀ ਹੋਵੇ, ਅਤੇ ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ ਰੁਕੋਗੇ।
• ਪੇਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਮਾਨਦਾਰੀ ਨਾਲ ਜਾਂਚੋ ਕਿ ਇਹ ਢੁਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। Green Apple ਕਿਸ ਲਈ ਬਣਿਆ ਹੈ ਅਤੇ ਇਹ ਹੋਰ ਪਲੇਟਫ਼ਾਰਮਾਂ ਨਾਲ ਕਿਵੇਂ ਤੁਲਦਾ ਹੈ ਬਾਰੇ ਸਾਡੀਆਂ ਗਾਈਡਾਂ ਇਸ ਲਈ ਲਿਖੀਆਂ ਗਈਆਂ ਹਨ ਕਿ ਤੁਸੀਂ ਸਾਨੂੰ ਚੁਣ ਵੀ ਸਕੋ ਅਤੇ ਰੱਦ ਵੀ ਕਰ ਸਕੋ।

ਆਪਣੇ ਆਪ ਤੋਂ ਪੁੱਛੋ

• ਸਾਡੀ ਲੀਡਰਸ਼ਿਪ ਨੇ ਇਸ ਸਾਲ ਕਿਹੜੀ ਸੰਗਠਨਾਤਮਕ ਸਮੱਸਿਆ ਬਾਰੇ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ ਸ਼ਿਕਾਇਤ ਕੀਤੀ ਹੈ?
• ਉਸ ਸਮੱਸਿਆ ਦੇ ਪਿਛਲੇ ਮਾਮਲੇ ਦੀ ਸਾਨੂੰ ਮੋਟੇ ਤੌਰ 'ਤੇ ਕੀ ਲਾਗਤ ਪਈ, ਉਨ੍ਹਾਂ ਸ਼ਬਦਾਂ ਵਿੱਚ ਜੋ CFO ਪਛਾਣੇ?
• ਜੇ ਇਹ ਪਲੇਟਫ਼ਾਰਮ ਹੁੰਦਾ ਤਾਂ ਕੌਣ ਕਿਹੜਾ ਫ਼ੈਸਲਾ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਲੈਂਦਾ, ਅਤੇ ਕੀ ਅਸੀਂ ਉਨ੍ਹਾਂ ਤੋਂ ਪੁੱਛਿਆ ਹੈ?
• ਨੱਬੇ ਦਿਨਾਂ ਦੇ ਪਾਇਲਟ ਦਾ ਕਿਹੜਾ ਨਤੀਜਾ ਸਾਨੂੰ ਵਿਸਥਾਰ ਲਈ ਯਕੀਨ ਦਿਵਾਏਗਾ, ਅਤੇ ਕਿਹੜਾ ਰੁਕਣ ਲਈ?
• ਕੀ ਅਸੀਂ ਇਹ ਕਿਸੇ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਖ਼ਰੀਦ ਰਹੇ ਹਾਂ, ਜਾਂ ਇਸ ਲਈ ਕਿ ਸਾਡੇ ਵਰਗੀਆਂ ਹੋਰ ਕੰਪਨੀਆਂ ਕੋਲ ਇਹ ਹੈ?

ਸਾਰ

ਸੀਨੀਅਰ ਲੀਡਰਸ਼ਿਪ ਸਾਫ਼ਟਵੇਅਰ ਲਈ ਪੈਸਾ ਨਹੀਂ ਦਿੰਦੀ। ਇਹ ਉਸ ਸਮੱਸਿਆ ਦੇ ਅੰਤ ਲਈ ਪੈਸਾ ਦਿੰਦੀ ਹੈ ਜਿਸ ਦੀ ਕੀਮਤ ਉਹ ਪਹਿਲਾਂ ਹੀ ਚੁਕਾ ਰਹੀ ਹੈ। ਉਸ ਸਮੱਸਿਆ ਦਾ ਨਾਂ ਲੀਡਰਸ਼ਿਪ ਦੇ ਆਪਣੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਲਓ, ਉਸ ਦੀ ਲਾਗਤ ਦਾ ਇਮਾਨਦਾਰ ਅੰਦਾਜ਼ਾ ਲਾਓ, ਦੱਸੋ ਕਿ ਕੌਣ ਵੱਖਰਾ ਫ਼ੈਸਲਾ ਲਵੇਗਾ, ਤੈਅ ਨਤੀਜੇ 'ਤੇ ਮਾਪੇ ਇੱਕ ਛੋਟੇ ਪਾਇਲਟ ਨਾਲ ਇਸ ਨੂੰ ਸਾਬਤ ਕਰੋ, ਅਤੇ ਪੜਾਅਵਾਰ ਵਚਨਬੱਧਤਾ ਮੰਗੋ। ਜੇ ਤੁਸੀਂ ਉਸ ਫ਼ੈਸਲੇ ਦਾ ਨਾਂ ਨਹੀਂ ਲੈ ਸਕਦੇ ਜੋ ਪਲੇਟਫ਼ਾਰਮ ਬਦਲੇਗਾ, ਤਾਂ ਸਭ ਤੋਂ ਭਰੋਸੇਯੋਗ ਬਿਜ਼ਨਸ ਕੇਸ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਪੇਸ਼ ਹੀ ਨਾ ਕਰੋ।