{
  "assessmentTests": {
    "project_management": {
      "subscales": {
        "scope": "ਸਕੋਪ",
        "schedule": "ਸਮਾਂ-ਸਾਰਣੀ",
        "risk": "ਜੋਖਮ",
        "stakeholders": "ਹਿੱਸੇਦਾਰ",
        "budget": "ਬਜਟ"
      },
      "name": "ਪ੍ਰੋਜੈਕਟ ਮੈਨੇਜਮੈਂਟ ਟੈਸਟ",
      "desc": "ਸਕੋਪ, ਸਮਾਂ-ਸਾਰਣੀ, ਜੋਖਮ, ਹਿੱਸੇਦਾਰ ਅਤੇ ਬਜਟ ਨਾਲ ਜੁੜੇ ਫੈਸਲੇ — waterfall ਅਤੇ agile ਦੋਵੇਂ ਢੰਗ ਰਲੇ-ਮਿਲੇ, ਕਿਸੇ ਖਾਸ ਟੂਲ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ।",
      "recommendation": "ਤੁਹਾਡੀਆਂ ਪ੍ਰੋਜੈਕਟ ਮੈਨੇਜਮੈਂਟ ਖੂਬੀਆਂ",
      "questions": [
        {
          "question": "ਪ੍ਰੋਜੈਕਟ ਅੱਧ ਵਿਚਕਾਰ ਹੈ ਅਤੇ ਇੱਕ ਹਿੱਸੇਦਾਰ ਅਜਿਹੀ ਫੀਚਰ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ ਜੋ ਸ਼ੁਰੂਆਤੀ ਲੋੜਾਂ ਵਿੱਚ ਕਦੇ ਸ਼ਾਮਲ ਹੀ ਨਹੀਂ ਸੀ, ਅਤੇ ਨਾ ਹੀ ਕੋਈ ਵਾਧੂ ਬਜਟ ਜਾਂ ਸਮਾਂ ਦਿੱਤਾ ਜਾ ਰਿਹਾ ਹੈ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸਹੀ ਕਦਮ ਕੀ ਹੈ?",
          "options": [
            {
              "icon": "",
              "label": "ਕਿਸੇ ਨੂੰ ਦੱਸੇ ਬਿਨਾਂ, ਵਿਹਲੇ ਸਮੇਂ ਵਿੱਚ ਚੁੱਪਚਾਪ ਇਸਨੂੰ ਜੋੜ ਦਿਓ ਤਾਂ ਜੋ ਕਿਸੇ ਨੂੰ ਵੀ ਰਸਮੀ ਤੌਰ 'ਤੇ ਫੈਸਲਾ ਨਾ ਲੈਣਾ ਪਵੇ"
            },
            {
              "icon": "",
              "label": "ਹਿੱਸੇਦਾਰ ਨਾਲ ਗੱਲ ਕੀਤੇ ਬਿਨਾਂ ਹੀ ਸਿੱਧਾ ਇਨਕਾਰ ਕਰ ਦਿਓ"
            },
            {
              "icon": "",
              "label": "ਇਸਨੂੰ change request ਵਜੋਂ ਦਰਜ ਕਰੋ ਅਤੇ ਵਚਨਬੱਧ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਲਾਗਤ ਅਤੇ ਸਮਾਂ-ਸਾਰਣੀ 'ਤੇ ਪੈਣ ਵਾਲੇ ਅਸਰ ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ"
            },
            {
              "icon": "",
              "label": "ਇਸਨੂੰ ਜੋੜ ਦਿਓ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਜਗ੍ਹਾ ਬਣਾਉਣ ਲਈ ਚੁੱਪਚਾਪ ਟੈਸਟਿੰਗ ਦਾ ਸਮਾਂ ਘਟਾ ਦਿਓ"
            }
          ]
        },
        {
          "question": "ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ \"Gold-plating\" ਦਾ ਮਤਲਬ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਅਣਕਿਆਸੇ ਹਾਲਾਤਾਂ ਲਈ ਵਾਧੂ ਬਜਟ ਰੱਖ ਲੈਣਾ"
            },
            {
              "icon": "",
              "label": "ਗਾਹਕ ਦੀ ਮੰਗ ਨਾਲੋਂ ਵੱਧ ਦਸਤਾਵੇਜ਼ (documentation) ਤਿਆਰ ਕਰਨਾ"
            },
            {
              "icon": "",
              "label": "ਕਿਸੇ ਕੰਮ ਲਈ ਅਸਲ ਲੋੜ ਜਾਂ ਸਮਾਂ-ਸਾਰਣੀ ਨਾਲੋਂ ਕਿਤੇ ਵੱਧ ਲੋਕ ਲਗਾ ਦੇਣਾ"
            },
            {
              "icon": "",
              "label": "ਜੋ ਸਕੋਪ ਜਾਂ ਸਹਿਮਤੀ ਵਿੱਚ ਸੀ ਉਸ ਤੋਂ ਵੱਧ ਦੇਣਾ, ਬਿਨਾਂ ਕਿਸੇ ਵਾਧੂ ਮੁੱਲ ਜਾਂ ਮਨਜ਼ੂਰੀ (sign-off) ਦੇ"
            }
          ]
        },
        {
          "question": "ਇੱਕ ਟੀਮ ਵਿਕਾਸ (development) ਦੌਰਾਨ ਲਗਾਤਾਰ ਛੋਟੇ-ਛੋਟੇ \"nice-to-have\" ਸੁਧਾਰ ਜੋੜਦੀ ਰਹਿੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਰਿਲੀਜ਼ ਦੀ ਤਾਰੀਖ ਵਾਰ-ਵਾਰ ਅੱਗੇ ਖਿਸਕਦੀ ਜਾਂਦੀ ਹੈ। ਇਸਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਕਿਵੇਂ ਬਿਆਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਸਮਾ-ਸੂਚੀ ਸਿਕੁੜਾ"
            },
            {
              "icon": "",
              "label": "ਓਵਰ ਰਨ"
            },
            {
              "icon": "",
              "label": "ਸਰੋਤ ਸਮਤਲਿਆ"
            },
            {
              "icon": "",
              "label": "ਸਰੰਜ ਫੈਲਾਅ"
            }
          ]
        },
        {
          "question": "ਇਹ ਸਭ ਤੋਂ ਸਪੱਸ਼ਟ ਸੰਕੇਤ ਹੈ ਕਿ ਮੰਗੀ ਗਈ ਫੀਚਰ ਸੱਚਮੁੱਚ ਸਕੋਪ ਤੋਂ ਬਾਹਰ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਟੀਮ ਨੂੰ ਪਸੰਦ ਨਹੀਂ:",
          "options": [
            {
              "icon": "",
              "label": "ਬਾਕੀ ਬਚੇ ਸਮੇਂ ਵਿੱਚ ਇਸਨੂੰ ਬਣਾਉਣਾ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਔਖਾ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਟੀਮ ਨੂੰ ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਇਹ ਵਿਚਾਰ ਪਸੰਦ ਨਹੀਂ ਅਤੇ ਉਹ ਇਸਨੂੰ ਬਣਾਉਣਾ ਨਹੀਂ ਚਾਹੁੰਦੀ"
            },
            {
              "icon": "",
              "label": "ਇਸਦਾ ਜ਼ਿਕਰ kickoff ਮੀਟਿੰਗ ਦੌਰਾਨ ਨਹੀਂ ਹੋਇਆ ਸੀ"
            },
            {
              "icon": "",
              "label": "ਇਹ ਮਨਜ਼ੂਰਸ਼ੁਦਾ scope baseline ਤੋਂ ਬਾਹਰ ਆਉਂਦੀ ਹੈ"
            }
          ]
        },
        {
          "question": "ਕਿਹੜਾ ਅਭਿਆਸ scope creep ਨੂੰ ਸਮਾਂ-ਸਾਰਣੀ ਵਿਗਾੜਨ ਤੋਂ ਸਭ ਤੋਂ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਰੋਕਦਾ ਹੈ?",
          "options": [
            {
              "icon": "",
              "label": "ਹਰ ਹਫ਼ਤੇ status ਮੀਟਿੰਗ ਕਰਨਾ"
            },
            {
              "icon": "",
              "label": "ਇੱਕ change-control ਪ੍ਰਕਿਰਿਆ ਜੋ ਨਵੇਂ ਸਕੋਪ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਲਾਗਤ ਅਤੇ ਸਮਾਂ-ਸਾਰਣੀ 'ਤੇ ਪੈਣ ਵਾਲੇ ਅਸਰ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦੀ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਵਿਸਤ੍ਰਿਤ Gantt chart ਨੂੰ ਹਮੇਸ਼ਾ ਅੱਪਡੇਟ ਰੱਖਣਾ"
            },
            {
              "icon": "",
              "label": "ਟੀਮ ਵਿੱਚ ਹੋਰ developers ਸ਼ਾਮਲ ਕਰਨਾ"
            }
          ]
        },
        {
          "question": "ਇੱਕ sprint-ਆਧਾਰਿਤ ਟੀਮ ਹਿੱਸੇਦਾਰਾਂ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਚੱਲ ਰਹੇ sprint ਵਿੱਚ ਸਿੱਧੇ ਨਵੇਂ ਕੰਮ ਪਾਉਣ ਦਿੰਦੀ ਰਹਿੰਦੀ ਹੈ। ਸਭ ਤੋਂ ਸਿਹਤਮੰਦ ਜਵਾਬ ਕੀ ਹੈ?",
          "options": [
            {
              "icon": "",
              "label": "ਮੌਜੂਦਾ sprint ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੱਦ ਕਰੋ, ਯੋਜਨਾਬੰਦੀ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੋ, ਅਤੇ ਨਵੇਂ ਸਕੋਪ ਨੂੰ ਤਾਜ਼ੀ ਬਣਾਈ ਯੋਜਨਾ ਵਿੱਚ ਜੋੜੋ"
            },
            {
              "icon": "",
              "label": "ਮੌਜੂਦਾ sprint ਦੀ ਵਚਨਬੱਧਤਾ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖੋ ਅਤੇ ਨਵੀਆਂ ਮੰਗਾਂ ਨੂੰ backlog grooming ਵੱਲ ਭੇਜੋ"
            },
            {
              "icon": "",
              "label": "ਕਿਸੇ ਨੂੰ ਦੱਸੇ ਬਿਨਾਂ ਚੁੱਪਚਾਪ ਓਨੇ ਹੀ ਮੌਜੂਦਾ ਕੰਮ ਹਟਾ ਦਿਓ"
            },
            {
              "icon": "",
              "label": "ਕੰਮ ਸਵੀਕਾਰ ਕਰ ਲਓ ਅਤੇ ਚੁੱਪਚਾਪ sprint ਦੀ ਮਿਆਦ ਵਧਾ ਦਿਓ"
            }
          ]
        },
        {
          "question": "ਪ੍ਰੋਜੈਕਟ ਦਾ \"critical path\" ਇਹ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਆਪਸ ਵਿੱਚ ਜੁੜੇ ਕੰਮਾਂ ਦਾ ਉਹ ਸਿਲਸਿਲਾ ਜੋ ਪ੍ਰੋਜੈਕਟ ਦੀ ਸਭ ਤੋਂ ਘੱਟ ਸੰਭਵ ਮਿਆਦ ਤੈਅ ਕਰਦਾ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਉਹ ਸੂਚੀ ਜਿਸ ਵਿੱਚ ਟੀਮ ਦੇ ਸਭ ਤੋਂ ਸੀਨੀਅਰ ਮੈਂਬਰਾਂ ਨੂੰ ਰਸਮੀ ਤੌਰ 'ਤੇ ਸੌਂਪੇ ਗਏ ਸਾਰੇ ਕੰਮ ਹਨ"
            },
            {
              "icon": "",
              "label": "ਉਹ ਕੰਮ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਪੂਰੀ ਪ੍ਰੋਜੈਕਟ ਯੋਜਨਾ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਵੱਧ ਪਛਾਣਿਆ ਗਿਆ ਜੋਖਮ ਹੁੰਦਾ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਉਹ ਕੰਮ ਜੋ ਬਜਟ ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਹਿੱਸਾ ਖਪਤ ਕਰਦੇ ਹਨ"
            }
          ]
        },
        {
          "question": "critical path 'ਤੇ ਪਿਆ ਇੱਕ ਕੰਮ ਤਿੰਨ ਦਿਨ ਪਿੱਛੇ ਖਿਸਕ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਯੋਜਨਾ ਵਿੱਚ ਹੋਰ ਕਿਤੇ ਵੀ ਕੋਈ ਤਬਦੀਲੀ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। ਪ੍ਰੋਜੈਕਟ ਦੀ ਪੂਰਾ ਹੋਣ ਦੀ ਤਾਰੀਖ:",
          "options": [
            {
              "icon": "",
              "label": "ਉਹੀ ਰਹੇਗੀ, ਕਿਉਂਕਿ critical-path ਕੰਮਾਂ ਕੋਲ ਆਪਣਾ float ਹੁੰਦਾ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਤਿੰਨ ਦਿਨ ਪਿੱਛੇ ਖਿਸਕ ਜਾਵੇਗੀ"
            },
            {
              "icon": "",
              "label": "ਆਪਣੇ ਆਪ ਤਿੰਨ ਦਿਨਾਂ ਤੋਂ ਵੱਧ ਪਿੱਛੇ ਖਿਸਕ ਜਾਵੇਗੀ"
            },
            {
              "icon": "",
              "label": "ਸਿਰਫ਼ ਉਦੋਂ ਖਿਸਕੇਗੀ ਜੇ ਉਹ ਕੰਮ ਬਜਟ ਤੋਂ ਵੀ ਵੱਧ ਜਾਵੇ"
            }
          ]
        },
        {
          "question": "critical path 'ਤੇ ਨਾ ਹੋਣ ਵਾਲੇ ਕਿਸੇ ਕੰਮ 'ਤੇ \"Float\" (ਜਾਂ slack) ਦਾ ਮਤਲਬ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਉਹ ਕੰਮ ਪ੍ਰੋਜੈਕਟ ਦੀ ਪੂਰਾ ਹੋਣ ਦੀ ਤਾਰੀਖ ਨੂੰ ਅੱਗੇ ਖਿਸਕਾਏ ਬਿਨਾਂ ਕਿੰਨਾ ਸਮਾਂ ਲੇਟ ਹੋ ਸਕਦਾ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਖਾਸ ਤੌਰ 'ਤੇ ਉਸ ਕੰਮ ਲਈ ਰੱਖੇ ਗਏ ਬਜਟ ਰਿਜ਼ਰਵ ਦਾ ਆਕਾਰ"
            },
            {
              "icon": "",
              "label": "ਇੱਕੋ ਵੇਲੇ ਕਿੰਨੇ ਲੋਕਾਂ ਨੂੰ ਇਸ 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ ਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਕੰਮ ਦੇ ਜ਼ਿੰਮੇਵਾਰ ਵਿਅਕਤੀ ਨੂੰ ਕਿੰਨੀ ਆਸਾਨੀ ਨਾਲ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ"
            }
          ]
        },
        {
          "question": "ਦੋ ਕੰਮ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਤੋਂ ਬਾਅਦ ਇੱਕ ਚੱਲਦੇ, ਕਿਉਂਕਿ ਇੱਕ ਦੂਜੇ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਦੀ ਬਜਾਏ ਓਵਰਲੈਪ ਕਰਕੇ ਅਤੇ ਥੋੜ੍ਹਾ ਵਾਧੂ ਜੋਖਮ ਸਵੀਕਾਰ ਕਰਕੇ, ਸਮਾਂ-ਸਾਰਣੀ ਛੋਟੀ ਕਰਨ ਲਈ ਕੁਝ ਹਿੱਸੇ ਵਿੱਚ ਸਮਾਂਤਰ (parallel) ਚਲਾਏ ਜਾਂਦੇ ਹਨ। ਇਸਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਕ੍ਰੈਸ਼ਿੰਗ"
            },
            {
              "icon": "",
              "label": "ਸਰੋਤ ਸਮਤਲਿਆ"
            },
            {
              "icon": "",
              "label": "ਤਿਜ਼ ਟਰੈਕਿੰਗ"
            },
            {
              "icon": "",
              "label": "ਦੋਬਾਰਾ ਅਧਾਰ ਨਿਰਧਾਰਣ"
            }
          ]
        },
        {
          "question": "ਸਿਰਫ਼ ਮਿਆਦ ਛੋਟੀ ਕਰਨ ਲਈ ਕਿਸੇ ਕੰਮ ਵਿੱਚ ਵਾਧੂ ਲੋਕ ਜਾਂ ਸਰੋਤ ਜੋੜਨਾ, ਅਤੇ ਬਦਲੇ ਵਿੱਚ ਵੱਧ ਲਾਗਤ ਸਵੀਕਾਰ ਕਰਨਾ, ਕਿਹਾ ਜਾਂਦਾ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਤਿਜ਼ ਟਰੈਕਿੰਗ"
            },
            {
              "icon": "",
              "label": "ਸਰੋਤ ਸਮਤਲਿਆ"
            },
            {
              "icon": "",
              "label": "ਕ੍ਰੈਸ਼ਿੰਗ"
            },
            {
              "icon": "",
              "label": "ਸਲੈਕ"
            }
          ]
        },
        {
          "question": "ਇੱਕ ਟੀਮ ਦੋ-ਹਫ਼ਤੇ ਦੇ sprints ਚਲਾਉਂਦੀ ਹੈ। ਲਗਾਤਾਰ ਤਿੰਨ sprints ਤੋਂ ਬਾਅਦ, ਅਸਲ velocity ਹਮੇਸ਼ਾ ਯੋਜਨਾਬੱਧ ਟੀਚੇ ਤੋਂ ਕਾਫ਼ੀ ਘੱਟ ਰਹਿੰਦੀ ਹੈ। ਸਭ ਤੋਂ ਲਾਹੇਵੰਦ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ?",
          "options": [
            {
              "icon": "",
              "label": "ਮੂਲ ਅੰਦਾਜ਼ੇ ਅਨੁਸਾਰ ਹੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਰਹੋ ਅਤੇ ਉਮੀਦ ਰੱਖੋ ਕਿ ਟੀਮ ਆਖਿਰਕਾਰ ਫੜ੍ਹ ਲਵੇਗੀ"
            },
            {
              "icon": "",
              "label": "ਅਸਲ velocity ਦੇ ਆਧਾਰ 'ਤੇ ਯੋਜਨਾ ਨੂੰ re-baseline ਕਰੋ"
            },
            {
              "icon": "",
              "label": "ਮੂਲ ਟੀਚਾ ਹਾਸਲ ਕਰਨ ਲਈ ਅਗਲੇ sprint ਵਿੱਚ ਹੋਰ ਲੋਕ ਜੋੜੋ"
            },
            {
              "icon": "",
              "label": "ਹਰ sprint ਦੀ ਮਿਆਦ ਵਧਾ ਦਿਓ ਤਾਂ ਜੋ ਅੰਦਰ ਹੋਰ ਕੰਮ ਸਮਾ ਜਾਵੇ"
            }
          ]
        },
        {
          "question": "ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ \"risk\" ਅਤੇ \"issue\" ਵਿੱਚ ਫਰਕ ਇਹ ਹੈ ਕਿ:",
          "options": [
            {
              "icon": "",
              "label": "ਜੋਖਮ (risk) ਹਮੇਸ਼ਾ ਨਾਂਹ-ਪੱਖੀ ਹੁੰਦਾ ਹੈ, ਜਦਕਿ issue ਸਕਾਰਾਤਮਕ ਵੀ ਹੋ ਸਕਦਾ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਜੋਖਮ ਨੂੰ sponsor ਟਰੈਕ ਕਰਦਾ ਹੈ, ਜਦਕਿ issue ਨੂੰ ਟੀਮ ਟਰੈਕ ਕਰਦੀ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਜੋਖਮ ਇੱਕ ਸੰਭਾਵਿਤ ਭਵਿੱਖੀ ਘਟਨਾ ਹੈ ਜੋ ਅਜੇ ਵਾਪਰੀ ਨਹੀਂ; issue ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਵਾਪਰ ਚੁੱਕੀ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਜੋਖਮ ਸਿਰਫ਼ ਬਜਟ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਜਦਕਿ issue ਸਿਰਫ਼ ਸਮਾਂ-ਸਾਰਣੀ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ"
            }
          ]
        },
        {
          "question": "ਘੱਟ ਸੰਭਾਵਨਾ ਵਾਲੇ ਪਰ ਜੇ ਵਾਪਰ ਜਾਵੇ ਤਾਂ ਵਿਨਾਸ਼ਕਾਰੀ ਅਸਰ ਪਾਉਣ ਵਾਲੇ ਜੋਖਮ ਨਾਲ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਨਜਿੱਠਣਾ ਚਾਹੀਦਾ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਸ਼ਾਇਦ ਇਹ ਵਾਪਰੇਗਾ ਹੀ ਨਹੀਂ"
            },
            {
              "icon": "",
              "label": "ਇਸ ਨਾਲ ਓਵੇਂ ਹੀ ਨਜਿੱਠਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਵੇਂ ਵੱਧ-ਸੰਭਾਵਨਾ, ਘੱਟ-ਅਸਰ ਵਾਲੇ ਜੋਖਮ ਨਾਲ"
            },
            {
              "icon": "",
              "label": "ਸਰਗਰਮੀ ਨਾਲ ਨਿਗਰਾਨੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਇੱਕ contingency ਯੋਜਨਾ ਤਿਆਰ ਰੱਖ ਕੇ, ਭਾਵੇਂ ਇਹ ਸੰਭਾਵਨਾ ਘੱਟ ਹੋਵੇ"
            },
            {
              "icon": "",
              "label": "ਲਿਖੇ ਅਤੇ ਨੋਟ ਕੀਤੇ ਜਾਣ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ risk register ਵਿੱਚੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ"
            }
          ]
        },
        {
          "question": "\"Risk mitigation\" ਦਾ ਮਤਲਬ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਜੋਖਮ ਨੂੰ ਜਿਵੇਂ ਦਾ ਤਿਵੇਂ ਸਵੀਕਾਰ ਕਰਨਾ ਅਤੇ ਸੋਚ-ਸਮਝ ਕੇ ਇਸ ਬਾਰੇ ਕੁਝ ਨਾ ਕਰਨ ਦਾ ਫੈਸਲਾ ਲੈਣਾ"
            },
            {
              "icon": "",
              "label": "ਜੋਖਮ ਦੀ ਸੰਭਾਵਨਾ ਜਾਂ ਅਸਰ ਘਟਾਉਣ ਲਈ ਪਹਿਲਾਂ ਹੀ ਕਦਮ ਚੁੱਕਣਾ"
            },
            {
              "icon": "",
              "label": "ਜੋਖਮ ਦੀ ਪੂਰੀ ਜ਼ਿੰਮੇਵਾਰੀ ਕਿਸੇ vendor ਜਾਂ ਤੀਜੀ ਧਿਰ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੌਂਪ ਦੇਣਾ"
            },
            {
              "icon": "",
              "label": "ਜੋਖਮ ਦੇ ਅਸਲ issue ਬਣਨ ਤੋਂ ਬਾਅਦ ਹੀ ਉਸ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇਣਾ"
            }
          ]
        },
        {
          "question": "ਇੱਕ ਉਸਾਰੀ (construction) ਪ੍ਰੋਜੈਕਟ ਇੱਕ ਅਹਿਮ ਸਮੱਗਰੀ ਲਈ ਸਿਰਫ਼ ਇੱਕੋ supplier 'ਤੇ ਨਿਰਭਰ ਹੈ, ਅਤੇ ਕੋਈ ਬੈਕਅੱਪ ਸਰੋਤ ਪਛਾਣਿਆ ਨਹੀਂ ਗਿਆ। ਇਸਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਕਿਵੇਂ ਬਿਆਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਸਿਰਫ਼ ਇੱਕ ਬਜਟ ਜੋਖਮ, ਇਸ ਤੋਂ ਵੱਧ ਕੁਝ ਵੀ ਅਹਿਮ ਨਹੀਂ"
            },
            {
              "icon": "",
              "label": "ਜੋਖਮ ਦੀ ਬਜਾਏ ਇੱਕ issue, ਕਿਉਂਕਿ ਅਜੇ ਤੱਕ ਕੁਝ ਗਲਤ ਨਹੀਂ ਹੋਇਆ"
            },
            {
              "icon": "",
              "label": "ਟਰੈਕ ਕਰਨ ਦੇ ਲਾਇਕ ਨਹੀਂ, ਕਿਉਂਕਿ supplier ਨੇ ਹਾਲੇ ਤੱਕ ਕੋਈ ਮੁਸ਼ਕਲ ਦੇ ਸੰਕੇਤ ਨਹੀਂ ਦਿਖਾਏ"
            },
            {
              "icon": "",
              "label": "ਇੱਕ single-point-of-failure ਜੋਖਮ, ਜਿਸਨੂੰ ਬੈਕਅੱਪ ਯੋਜਨਾ ਦੀ ਲੋੜ ਹੈ"
            }
          ]
        },
        {
          "question": "risk register 'ਤੇ ਕਿਸੇ ਖਾਸ ਜੋਖਮ ਦਾ \"ਮਾਲਕ\" (owner) ਕਿਸਨੂੰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ?",
          "options": [
            {
              "icon": "",
              "label": "ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ project sponsor, ਭਾਵੇਂ ਜੋਖਮ ਦਾ ਵਿਸ਼ਾ ਕੁਝ ਵੀ ਹੋਵੇ"
            },
            {
              "icon": "",
              "label": "ਇੱਕ ਨਾਮਜ਼ਦ ਵਿਅਕਤੀ ਜੋ ਇਸਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਅਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਜਵਾਬਦੇਹ ਹੋਵੇ"
            },
            {
              "icon": "",
              "label": "ਕੋਈ ਖਾਸ ਵਿਅਕਤੀ ਨਹੀਂ — ਜੋਖਮ ਪੂਰੀ ਟੀਮ ਦੀ ਸਾਂਝੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਜਿਸਨੇ ਵੀ ਪਹਿਲਾਂ ਇਹ ਜੋਖਮ ਉਠਾਇਆ, ਉਹ ਹਮੇਸ਼ਾ ਲਈ, ਭਾਵੇਂ ਉਸਦੀ ਭੂਮਿਕਾ ਕੁਝ ਵੀ ਹੋਵੇ"
            }
          ]
        },
        {
          "question": "ਪ੍ਰੋਜੈਕਟ ਦੀ ਸ਼ੁਰੂਆਤ (kickoff) ਵੇਲੇ ਦਰਮਿਆਨੀ-ਸੰਭਾਵਨਾ, ਦਰਮਿਆਨੇ-ਅਸਰ ਵਾਲੇ ਦਰਜੇ ਦੇ ਜੋਖਮ ਨਾਲ ਇਸ ਤਰ੍ਹਾਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਪ੍ਰੋਜੈਕਟ ਅੱਗੇ ਵਧਣ ਦੇ ਨਾਲ-ਨਾਲ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਮੁੜ-ਮੁਲਾਂਕਣ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਪ੍ਰੋਜੈਕਟ ਦੀ ਪੂਰੀ ਮਿਆਦ ਲਈ ਉਸੇ ਦਰਜੇ 'ਤੇ ਸਥਿਰ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਪ੍ਰੋਜੈਕਟ ਦਾ ਅੱਧਾ ਸਫ਼ਰ ਪੂਰਾ ਹੁੰਦਿਆਂ ਹੀ register ਵਿੱਚੋਂ ਹਟਾ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਸਿਰਫ਼ ਇੱਕ ਆਮ status ਮੀਟਿੰਗ ਤੋਂ ਬਾਅਦ ਆਪਣੇ ਆਪ ਉੱਚੇ ਦਰਜੇ 'ਤੇ ਪਹੁੰਚਾ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ"
            }
          ]
        },
        {
          "question": "ਦੋ ਹਿੱਸੇਦਾਰ ਪ੍ਰੋਜੈਕਟ ਟੀਮ ਨੂੰ ਇੱਕੋ ਫੀਚਰ ਬਾਰੇ ਆਪਸ ਵਿੱਚ ਟਕਰਾਉਂਦੀਆਂ ਤਰਜੀਹਾਂ ਦੱਸਦੇ ਹਨ। ਸਭ ਤੋਂ ਅਸਰਦਾਰ ਪਹਿਲਾ ਕਦਮ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਫੈਸਲੇ ਲਈ ਉਸ ਵਿਅਕਤੀ ਕੋਲ ਮਾਮਲਾ ਲੈ ਜਾਣਾ ਜਿਸ ਕੋਲ ਇਸਨੂੰ ਸੁਲਝਾਉਣ ਦਾ ਅਧਿਕਾਰ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਦੋਵੇਂ ਵਰਜ਼ਨ ਬਣਾਉਣਾ ਅਤੇ ਮਾਰਕੀਟ ਨੂੰ ਫੈਸਲਾ ਕਰਨ ਦੇਣਾ ਕਿ ਕਿਹੜਾ ਟਿਕਦਾ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਜਿਸ ਹਿੱਸੇਦਾਰ ਨੇ ਪਹਿਲਾਂ ਮੰਗ ਕੀਤੀ, ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਉਸਦੀ ਗੱਲ ਮੰਨ ਲੈਣਾ"
            },
            {
              "icon": "",
              "label": "ਜਿਹੜੀ ਮੰਗ ਵੱਧ ਸੀਨੀਅਰ ਲੱਗੇ, ਕਿਸੇ ਨਾਲ ਪੁਸ਼ਟੀ ਕੀਤੇ ਬਿਨਾਂ ਚੁੱਪਚਾਪ ਉਸਨੂੰ ਮੰਨ ਲੈਣਾ"
            }
          ]
        },
        {
          "question": "ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ \"communication plan\" ਮੁੱਖ ਤੌਰ 'ਤੇ ਇਹ ਤੈਅ ਕਰਨ ਲਈ ਹੁੰਦੀ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਤਿਆਰ ਉਤਪਾਦ ਦੇ ਜਨਤਕ launch ਲਈ ਯੋਜਨਾਬੱਧ marketing ਸੰਦੇਸ਼ ਰਣਨੀਤੀ"
            },
            {
              "icon": "",
              "label": "ਪੂਰੀ ਕੰਪਨੀ ਵਿੱਚ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਰਸਮੀ ਰਿਪੋਰਟਿੰਗ ਢਾਂਚਾ ਅਤੇ org chart"
            },
            {
              "icon": "",
              "label": "ਕਿਸਨੂੰ ਕਿਹੜੀ ਜਾਣਕਾਰੀ, ਕਿੰਨੀ ਵਾਰ, ਅਤੇ ਕਿਹੜੇ ਮਾਧਿਅਮ ਰਾਹੀਂ ਚਾਹੀਦੀ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਮੀਟਿੰਗ-ਰੂਮ ਬੁਕਿੰਗ ਦੀ ਸਮਾਂ-ਸਾਰਣੀ"
            }
          ]
        },
        {
          "question": "ਇੱਕ ਅਹਿਮ ਹਿੱਸੇਦਾਰ ਦੋ ਹਫ਼ਤਿਆਂ ਤੋਂ ਚੁੱਪ ਹੈ ਅਤੇ review ਮੰਗਾਂ ਦਾ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਦੇ ਰਿਹਾ, ਅਤੇ ਇੱਕ milestone ਉਸਦੀ ਮਨਜ਼ੂਰੀ (sign-off) 'ਤੇ ਨਿਰਭਰ ਹੈ। ਸਭ ਤੋਂ ਵਧੀਆ ਅਗਲਾ ਕਦਮ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਸਿੱਧਾ ਮਾਮਲਾ ਉੱਪਰ ਲੈ ਜਾਣਾ, ਰੁਕੇ ਹੋਏ milestone ਅਤੇ ਉਸਦੇ ਅਸਰ ਦਾ ਨਾਮ ਲੈ ਕੇ"
            },
            {
              "icon": "",
              "label": "ਜਦੋਂ ਤੱਕ ਹਿੱਸੇਦਾਰ ਆਪਣੇ ਆਪ ਜਵਾਬ ਨਾ ਦੇਵੇ, ਬੇਹੱਦ ਸਮੇਂ ਤੱਕ ਉਡੀਕਣਾ"
            },
            {
              "icon": "",
              "label": "ਮਨਜ਼ੂਰੀ ਤੋਂ ਬਿਨਾਂ ਹੀ milestone ਤੋਂ ਅੱਗੇ ਵਧ ਜਾਣਾ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ ਦੱਸਣਾ"
            },
            {
              "icon": "",
              "label": "ਉਹਨਾਂ 'ਤੇ ਨਿਰਭਰ milestone ਨੂੰ ਚੁੱਪਚਾਪ ਰੱਦ ਕਰ ਦੇਣਾ"
            }
          ]
        },
        {
          "question": "ਜਦੋਂ project sponsor ਅਤੇ ਅੰਤਿਮ-ਵਰਤੋਂਕਾਰ (end-user) ਸਮੂਹ ਕਿਸੇ ਲੋੜ ਦੀ ਤਰਜੀਹ ਬਾਰੇ ਅਸਹਿਮਤ ਹੋਣ, ਅਤੇ sponsor ਕੋਲ ਬਜਟ ਦਾ ਅਧਿਕਾਰ ਹੋਵੇ, ਤਾਂ ਪ੍ਰੋਜੈਕਟ ਟੀਮ ਨੂੰ ਚਾਹੀਦਾ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਦੋਵੇਂ ਦ੍ਰਿਸ਼ਟੀਕੋਣ sponsor ਸਾਹਮਣੇ ਰੱਖਣੇ ਅਤੇ ਅੰਤਿਮ ਫੈਸਲਾ ਉਹਨਾਂ ਨੂੰ ਲੈਣ ਦੇਣਾ"
            },
            {
              "icon": "",
              "label": "ਆਪਣੇ ਆਪ ਅੰਤਿਮ-ਵਰਤੋਂਕਾਰਾਂ ਦਾ ਪੱਖ ਲੈਣਾ, ਕਿਉਂਕਿ ਉਹੀ ਉਤਪਾਦ ਵਰਤਣਗੇ"
            },
            {
              "icon": "",
              "label": "ਕਿਸੇ ਵੀ ਧਿਰ ਨਾਲ ਠੀਕ ਤਰ੍ਹਾਂ ਸਲਾਹ ਕੀਤੇ ਬਿਨਾਂ ਵਿਚਕਾਰਲਾ ਰਾਹ ਕੱਢ ਲੈਣਾ"
            },
            {
              "icon": "",
              "label": "ਟਕਰਾਅ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਚਣ ਲਈ ਫੈਸਲੇ ਨੂੰ ਬੇਹੱਦ ਸਮੇਂ ਲਈ ਟਾਲ ਦੇਣਾ"
            }
          ]
        },
        {
          "question": "ਪ੍ਰੋਜੈਕਟ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਸਾਰੇ ਅਹਿਮ ਹਿੱਸੇਦਾਰਾਂ ਦੀ ਪਛਾਣ ਨਾ ਕਰ ਸਕਣ ਦਾ ਮੁੱਖ ਜੋਖਮ ਇਹ ਹੈ ਕਿ:",
          "options": [
            {
              "icon": "",
              "label": "ਪ੍ਰੋਜੈਕਟ ਆਪਣੇ ਆਪ ਬਜਟ ਤੋਂ ਵੱਧ ਜਾਵੇਗਾ"
            },
            {
              "icon": "",
              "label": "ਟੀਮ ਕੋਲ ਆਖਿਰਕਾਰ ਲੋੜੀਂਦੇ ਲੋਕਾਂ ਦੀ ਘਾਟ ਰਹਿ ਜਾਵੇਗੀ"
            },
            {
              "icon": "",
              "label": "ਅਸਲ ਪ੍ਰਭਾਵ ਰੱਖਣ ਵਾਲਾ ਕੋਈ ਵਿਅਕਤੀ ਦੇਰ ਨਾਲ ਸਾਹਮਣੇ ਆਉਂਦਾ ਹੈ ਅਤੇ ਮਹਿੰਗਾ ਦੁਬਾਰਾ-ਕੰਮ (rework) ਕਰਵਾ ਦਿੰਦਾ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਸਮਾਂ-ਸਾਰਣੀ ਵਿੱਚ ਆਖਿਰਕਾਰ ਕੋਈ critical path ਹੀ ਨਹੀਂ ਬਚੇਗਾ"
            }
          ]
        },
        {
          "question": "ਮੁੱਖ ਟੀਮ ਤੋਂ ਬਾਹਰ ਦਾ ਇੱਕ ਹਿੱਸੇਦਾਰ ਇੱਕ ਵਿਸਤ੍ਰਿਤ ਹਫ਼ਤਾਵਾਰੀ status ਰਿਪੋਰਟ ਮੰਗਦਾ ਹੈ ਜਿਸਨੂੰ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਘੰਟੇ ਲੱਗਦੇ ਹਨ, ਪਰ ਉਸ ਜਾਣਕਾਰੀ ਦੀ ਕੋਈ ਸਪੱਸ਼ਟ ਵਰਤੋਂ ਨਹੀਂ। ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕਾ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਪੁੱਛਣਾ ਕਿ ਉਹ ਇਹ ਅੱਪਡੇਟ ਕਿਹੜੇ ਫੈਸਲਿਆਂ ਲਈ ਵਰਤਦੇ ਹਨ, ਅਤੇ ਰਿਪੋਰਟ ਨੂੰ ਉਸ ਮੁਤਾਬਕ ਢਾਲਣਾ"
            },
            {
              "icon": "",
              "label": "ਤਿਆਰ ਕਰਨ ਦੀ ਲਾਗਤ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਹਰ ਹਫ਼ਤੇ ਓਹੀ ਪੂਰੀ ਵਿਸਤ੍ਰਿਤ ਰਿਪੋਰਟ ਭੇਜਦੇ ਰਹਿਣਾ"
            },
            {
              "icon": "",
              "label": "ਉਹਨਾਂ ਨੂੰ ਕੋਈ ਵੀ ਅੱਪਡੇਟ ਭੇਜਣ ਤੋਂ ਬਿਲਕੁਲ ਇਨਕਾਰ ਕਰ ਦੇਣਾ"
            },
            {
              "icon": "",
              "label": "ਅਸਲ ਮੰਗ ਨੂੰ ਸਮਝੇ ਬਿਨਾਂ ਰਿਪੋਰਟਿੰਗ ਦਾ ਕੰਮ ਸਭ ਤੋਂ ਜੂਨੀਅਰ ਟੀਮ ਮੈਂਬਰ ਨੂੰ ਸੌਂਪ ਦੇਣਾ"
            }
          ]
        },
        {
          "question": "ਇੱਕ ਪ੍ਰੋਜੈਕਟ 50% ਪੂਰਾ ਹੋਇਆ ਹੈ ਪਰ ਪਹਿਲਾਂ ਹੀ ਆਪਣੇ ਬਜਟ ਦਾ 70% ਖਰਚ ਕਰ ਚੁੱਕਾ ਹੈ, ਅਤੇ ਸਕੋਪ ਵਿੱਚ ਕੋਈ ਬਦਲਾਅ ਨਹੀਂ ਹੋਇਆ। ਇਹ ਸਭ ਤੋਂ ਵੱਧ ਸੰਭਾਵਨਾ ਕਿਸ ਗੱਲ ਦਾ ਸੰਕੇਤ ਹੈ?",
          "options": [
            {
              "icon": "",
              "label": "ਸਿਹਤਮੰਦ ਖਰਚਾ, ਕਿਉਂਕਿ ਲਗਭਗ ਹਰ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਵੱਧ ਲਾਗਤ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਆਉਂਦੀ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਚਿੰਤਾ ਦੀ ਕੋਈ ਗੱਲ ਨਹੀਂ, ਜਿੰਨਾ ਚਿਰ deadline ਟਰੈਕ 'ਤੇ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਇਹ ਸੰਕੇਤ ਕਿ ਮੂਲ ਬਜਟ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਰੱਖਿਆ ਗਿਆ ਸੀ"
            },
            {
              "icon": "",
              "label": "ਇੱਕ ਲਾਗਤ overrun ਜਿਸਦੀ ਜਾਂਚ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ"
            }
          ]
        },
        {
          "question": "ਪ੍ਰੋਜੈਕਟ ਬਜਟ ਵਿੱਚ \"contingency reserve\" ਦਾ ਮਕਸਦ ਇਹ ਕਵਰ ਕਰਨਾ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਪੂਰੀ ਕੰਪਨੀ ਦੇ ਬਜਟ ਵਿੱਚ ਆਮ ਮਹਿੰਗਾਈ (inflation)"
            },
            {
              "icon": "",
              "label": "ਸਕੋਪ ਵਿੱਚ ਉਹ ਬਦਲਾਅ ਜੋ ਗਾਹਕ ਬਾਅਦ ਵਿੱਚ ਮੰਗੇ"
            },
            {
              "icon": "",
              "label": "ਪ੍ਰੋਜੈਕਟ ਮੈਨੇਜਰ ਦਾ ਆਪਣਾ ਮਰਜ਼ੀ ਦਾ ਖਰਚਾ, ਬਿਨਾਂ ਕਿਸੇ ਹਿਸਾਬ-ਕਿਤਾਬ ਦੇ"
            },
            {
              "icon": "",
              "label": "ਉਹ ਜੋਖਮ ਜੋ ਪਹਿਲਾਂ ਹੀ ਪਛਾਣੇ ਅਤੇ ਜਾਣੇ ਜਾ ਚੁੱਕੇ ਹਨ"
            }
          ]
        },
        {
          "question": "ਇੱਕ vendor ਵੱਧ ਕੀਮਤ 'ਤੇ ਕੋਈ ਹਿੱਸਾ (component) ਜਲਦੀ ਪਹੁੰਚਾਉਣ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ। ਸਵੀਕਾਰ ਕਰਨਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਮੁੱਖ ਤੌਰ 'ਤੇ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਹਮੇਸ਼ਾ ਪੇਸ਼ਕਸ਼ ਸਵੀਕਾਰ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਕਿਉਂਕਿ ਕੀਮਤ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਜਲਦੀ ਡਿਲੀਵਰੀ ਹਮੇਸ਼ਾ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਕੀ ਸਮਾਂ-ਸਾਰਣੀ ਵਿੱਚ ਹੋਣ ਵਾਲਾ ਫਾਇਦਾ ਲੋੜੀਂਦਾ ਹੈ ਅਤੇ ਕੀ ਲਾਗਤ ਬਜਟ ਵਿੱਚ ਫਿੱਟ ਬੈਠਦੀ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਹਮੇਸ਼ਾ ਪੇਸ਼ਕਸ਼ ਠੁਕਰਾ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਿਉਂਕਿ ਮੂਲ ਬਜਟ ਹਰ ਹਾਲਤ ਵਿੱਚ ਸਥਿਰ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਜੋ ਵੀ ਬਦਲ vendor ਸਿਫਾਰਸ਼ ਕਰੇ, ਉਹੀ ਚੁਣ ਲੈਣਾ"
            }
          ]
        },
        {
          "question": "Budget variance ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਇਸ ਤਰ੍ਹਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "contingency reserve ਦੀ ਕੁੱਲ ਰਕਮ ਜੋ ਹਾਲੇ ਬਚੀ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਜੋ ਖਰਚ ਕਰਨ ਦੀ ਯੋਜਨਾ ਸੀ ਅਤੇ ਜੋ ਅਸਲ ਵਿੱਚ ਖਰਚ ਹੋਇਆ, ਉਹਨਾਂ ਵਿਚਲਾ ਫਰਕ"
            },
            {
              "icon": "",
              "label": "ਹੁਣ ਤੱਕ ਜਮ੍ਹਾਂ ਕੀਤੀਆਂ change requests ਦੀ ਗਿਣਤੀ"
            },
            {
              "icon": "",
              "label": "ਪ੍ਰਾਪਤ ਹੋਏ ਸਭ ਤੋਂ ਵੱਧ ਅਤੇ ਸਭ ਤੋਂ ਘੱਟ vendor quotes ਵਿਚਲਾ ਫਰਕ"
            }
          ]
        },
        {
          "question": "ਪ੍ਰੋਜੈਕਟ ਅੱਧ ਵਿਚਕਾਰ ਹੈ, ਅਸਲ ਲਾਗਤ ਬਜਟ ਕੀਤੀ ਰਕਮ ਦੇ ਨੇੜੇ-ਤੇੜੇ ਚੱਲ ਰਹੀ ਹੈ, ਪਰ ਯੋਜਨਾਬੱਧ ਨਾਲੋਂ ਕਿਤੇ ਘੱਟ deliverables ਪੂਰੇ ਹੋਏ ਹਨ। ਇਹ ਕਿਸ ਗੱਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ?",
          "options": [
            {
              "icon": "",
              "label": "ਪ੍ਰੋਜੈਕਟ ਵਿੱਤੀ ਤੌਰ 'ਤੇ ਬਿਲਕੁਲ ਠੀਕ ਹੈ, ਕਿਸੇ ਵੀ ਚੀਜ਼ 'ਤੇ ਧਿਆਨ ਦੇਣ ਦੀ ਲੋੜ ਨਹੀਂ"
            },
            {
              "icon": "",
              "label": "ਅਸਲ ਕਾਰਨ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਬਜਟ ਤੁਰੰਤ ਵਧਾ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਟੀਮ ਘੱਟ ਖਰਚ ਕਰ ਰਹੀ ਹੈ ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ ਲਾਗਤ ਦੇ ਨਵਾਂ ਸਕੋਪ ਸਮੋ ਸਕਦੀ ਹੈ"
            },
            {
              "icon": "",
              "label": "ਖਰਚ ਦੇ ਮੁਕਾਬਲੇ ਪ੍ਰੋਜੈਕਟ ਸਮਾਂ-ਸਾਰਣੀ ਤੋਂ ਪਿੱਛੇ ਹੈ"
            }
          ]
        },
        {
          "question": "ਜਦੋਂ ਕੋਈ ਪ੍ਰੋਜੈਕਟ ਬਜਟ ਤੋਂ ਵੱਧ ਜਾਣ ਵੱਲ ਵਧ ਰਿਹਾ ਹੋਵੇ, ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਲਾਹੇਵੰਦ ਪਹਿਲਾ ਕਦਮ ਹੈ:",
          "options": [
            {
              "icon": "",
              "label": "ਇਹ ਪਛਾਣਨਾ ਕਿ ਕਿਹੜੀਆਂ ਲਾਗਤ ਸ਼੍ਰੇਣੀਆਂ ਅਸਲ ਵਿੱਚ overrun ਦਾ ਕਾਰਨ ਬਣ ਰਹੀਆਂ ਹਨ"
            },
            {
              "icon": "",
              "label": "ਤੁਰੰਤ ਟੀਮ ਨੂੰ ਅੱਧਾ ਘਟਾ ਦੇਣਾ"
            },
            {
              "icon": "",
              "label": "ਬਿਨਾਂ ਕਿਸੇ ਹੋਰ ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ sponsor ਤੋਂ ਹੋਰ ਪੈਸੇ ਮੰਗਣਾ"
            },
            {
              "icon": "",
              "label": "ਹਰ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਬਰਾਬਰ ਸਾਰਾ ਖਰਚਾ ਰੋਕ ਦੇਣਾ"
            }
          ]
        }
      ],
      "results": {
        "beginner": {
          "name": "ਸ਼ੁਰੂਆਤੀ",
          "desc": "ਤੁਸੀਂ ਹੁਣੇ ਇਹ ਸਮਝਣਾ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹੋ ਕਿ ਪ੍ਰੋਜੈਕਟ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਚੱਲਦੇ ਹਨ — ਸਕੋਪ, ਸਮਾਂ-ਸਾਰਣੀ, ਜੋਖਮ, ਹਿੱਸੇਦਾਰ ਅਤੇ ਬਜਟ ਹਾਲੇ ਵੀ ਇੱਕ ਜੁੜੇ ਹੋਏ ਸਿਸਟਮ ਦੀ ਬਜਾਏ ਵੱਖੋ-ਵੱਖਰੇ ਵਿਸ਼ੇ ਜਾਪਦੇ ਹਨ।",
          "recommendation": "ਇੱਕ ਸਮੇਂ 'ਤੇ ਇੱਕ ਵਿਸ਼ੇ 'ਤੇ ਧਿਆਨ ਦਿਓ, ਸਕੋਪ ਤੋਂ ਸ਼ੁਰੂ ਕਰਕੇ: change request ਨੂੰ ਪਛਾਣਨਾ ਸਿੱਖੋ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਇਹ scope creep ਬਣ ਜਾਵੇ।"
        },
        "intermediate": {
          "name": "ਦਰਮਿਆਨਾ",
          "desc": "ਤੁਸੀਂ ਪ੍ਰੋਜੈਕਟ ਦੇ ਰੋਜ਼ਾਨਾ ਦੇ ਕੰਮਾਂ ਨੂੰ ਵਧੀਆ ਢੰਗ ਨਾਲ ਸੰਭਾਲਦੇ ਹੋ — ਤੁਸੀਂ ਸਮਾਂ-ਸਾਰਣੀ ਪੜ੍ਹ ਸਕਦੇ ਹੋ, ਜੋਖਮ ਦਰਜ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਹਿੱਸੇਦਾਰ ਦੀ ਮੰਗ ਨੂੰ ਸਹੀ ਥਾਂ ਭੇਜ ਸਕਦੇ ਹੋ — ਪਰ ਇਹਨਾਂ ਵਿਚਕਾਰਲੇ ਔਖੇ trade-offs ਲਈ ਹਾਲੇ ਵੀ ਵਾਧੂ ਸੋਚ-ਵਿਚਾਰ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ।",
          "recommendation": "trade-off ਸਵਾਲਾਂ ਦਾ ਅਭਿਆਸ ਕਰੋ: ਕਦੋਂ ਤੇਜ਼ vendor ਚੁਣਨਾ ਸਮਝਦਾਰੀ ਹੈ, ਕਦੋਂ re-baselining ਟੀਮ 'ਤੇ ਵੱਧ ਦਬਾਅ ਪਾਉਣ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ।"
        },
        "advanced": {
          "name": "ਉੱਨਤ",
          "desc": "ਤੁਸੀਂ ਸਕੋਪ, ਸਮਾਂ-ਸਾਰਣੀ, ਜੋਖਮ, ਹਿੱਸੇਦਾਰ ਅਤੇ ਬਜਟ — ਹਰ ਪੱਖ ਵਿੱਚ ਸਹੀ ਫੈਸਲੇ ਲੈਂਦੇ ਹੋ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਜਾਣਦੇ ਹੋ ਕਿ ਜਦੋਂ ਦੋ ਗੱਲਾਂ ਟਕਰਾਉਣ ਤਾਂ ਪਹਿਲਾਂ ਕਿਹੜਾ ਪੱਖ ਸੰਭਾਲਣਾ ਹੈ।",
          "recommendation": "ਔਖੇ ਮਾਮਲਿਆਂ ਨੂੰ ਹੋਰ ਤਿੱਖਾ ਕਰੋ — ਘੱਟ-ਸੰਭਾਵਨਾ/ਵੱਧ-ਅਸਰ ਵਾਲਾ ਜੋਖਮ, ਚੁੱਪ ਹਿੱਸੇਦਾਰ, ਲਾਗਤ ਟਰੈਕ 'ਤੇ ਪਰ ਸਮਾਂ-ਸਾਰਣੀ ਪਿੱਛੇ — ਜਿੱਥੇ ਸਪੱਸ਼ਟ ਦਿਸਣ ਵਾਲਾ ਜਵਾਬ ਆਮ ਤੌਰ 'ਤੇ ਗਲਤ ਹੁੰਦਾ ਹੈ।"
        },
        "expert": {
          "name": "ਮਾਹਿਰ",
          "desc": "ਤੁਸੀਂ ਪ੍ਰੋਜੈਕਟ ਦੇ ਹਾਲਾਤ ਨੂੰ ਓਸੇ ਤਰ੍ਹਾਂ ਪੜ੍ਹਦੇ ਹੋ ਜਿਵੇਂ ਇੱਕ ਤਜਰਬੇਕਾਰ PM ਪੜ੍ਹਦਾ ਹੈ: ਤੇਜ਼, ਕਿਸੇ ਖਾਸ ਟੂਲ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ, ਅਤੇ ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਕਿ ਟੀਮ waterfall ਵਰਤਦੀ ਹੈ ਜਾਂ agile — ਬੁਨਿਆਦੀ ਫੈਸਲੇ ਇੱਕੋ ਜਿਹੇ ਹੀ ਰਹਿੰਦੇ ਹਨ।",
          "recommendation": "ਮੈਂਟਰਿੰਗ ਕਰਨ ਜਾਂ ਪ੍ਰੋਜੈਕਟ retrospectives ਚਲਾਉਣ ਬਾਰੇ ਸੋਚੋ — trade-offs ਬਾਰੇ ਤੁਹਾਡੀ ਸੂਝ ਪਹਿਲਾਂ ਹੀ ਕਿਤਾਬੀ ਜਵਾਬਾਂ ਤੋਂ ਅੱਗੇ ਹੈ।"
        }
      },
      "retakePrompt": {
        "lastResult": "ਤੁਹਾਡਾ ਪਿਛਲਾ ਨਤੀਜਾ: {result}",
        "evolvedHint": "ਅਸਲ ਪ੍ਰੋਜੈਕਟ ਤਜਰਬੇ ਨਾਲ ਸੂਝ-ਬੂਝ ਹੋਰ ਤਿੱਖੀ ਹੁੰਦੀ ਹੈ — ਦੇਖੋ ਹੁਣ ਤੁਸੀਂ ਕਿੱਥੇ ਖੜ੍ਹੇ ਹੋ।",
        "retakeButton": "ਟੈਸਟ ਦੁਬਾਰਾ ਦਿਓ"
      },
      "optionOrderVersion": "24bd766649f91087"
    }
  },
  "testNames": {
    "project-management": "ਪ੍ਰੋਜੈਕਟ ਮੈਨੇਜਮੈਂਟ ਟੈਸਟ"
  }
}