Are you looking for any Project Management Courses in Mumbai or Project Management Courses in Delhi or PMP Certification Training or so on ? Have a look at below article. “When I took up my new project, the objectives, needs analysis, feasibility study, and steps that were needed to achieve project goals were well planned. However, as the project took off, the scope started changing. This was partly due to the need to keep pace with changing customer demand, and partly due to overlooking the many facets of the project that seemed obvious,” says Khushi, a project manager for a construction project in Mumbai, India. This is not uncommon; often requirements gathering and analysis are done in a detailed manner during project initiation and planning stages. Subsequently, the project scope goes through revisions, overlooking the impact on budget and schedule overruns. The project manager often procrastinates critical analyses of changed requirements, putting them on the back burner, while being blissfully oblivious of the future repercussions. It is a VUCA world—volatile, uncertain, complex, and ambiguous. Project management is no exception. Customers are more demanding than ever. The rapidly changing business environment often forces customers to change their expectations from deliverables, resulting in project scope creep. The VUCA world has redefined requirements gathering and gap analysis to a dynamic concept. “We often prioritize requirements and plan accordingly, based on the immediate need of the hour. We try accommodating these small changes within the planned framework and assume to still adhere to budget and time constraints,” remarks Khushi. Gradually, “small changes” sum up to result in “big changes,” thereby leading to significant overruns in budget and schedule, without any formal acknowledgement. Gaurav, who works as an IT project lead in a reputed firm, affirms, “In such situations, the final project hardly resembles the original or initial plan.” Welcome to scope creep! A bit about project management: To achieve a specific target, a project is often measured by achieving quadruple constraints; namely, budget, schedule, scope, and quality. Budget, schedule, and quality are often dependent on project scope. Changes in scope can distort project outcomes. Management of scope creep involves effective requirements analysis, followed with optimum resource allocation and involvement of relevant stakeholders. Ineffective requirements gathering and analysis can adversely affect the resource allocation and stakeholder involvement. Leadership support, coupled with the project manager’s vision and their flexibility to accommodate change management, can prevent scope creep. In addition, prudent planning, monitoring, and controlling of requirements, and subsequent due diligence, can control scope creep and improve the chances of project success. Project Myopia Having said that, project success is not all about meeting the quadruple constraints. Undeniably, there are some factors outside the ambit of the project manager, but not all. As Sudhir, a young IT project manager, puts it, “There are two dimensions to this: the influence of external stakeholders, principally the changing customers’ expectations and the internal stakeholders, and the project manager and his or her team. It is seldom the case that the external stakeholder will restrict the project manager from redefining the project scope to accommodate the changed expectations on project deliverables.”
Scope creep is not a situation created by external stakeholders or customers. There is a behavioral aspect to it. A flexible mind-set of the project manager that is receptive to change, without having a myopic and rigid view of initial project requirements, can do the magic. Gaurav Jana, an IT project lead, says, “We are often emotionally attached to the initial planning, based on which deadlines are determined. Then we keep adding on, without formally providing additional leeway.” Improper prioritization of work schedules, incorporating technological improvements, and changes in factors external to the system (e.g., recession, government regulatory policies, natural disasters, etc.), can also lead to scope creep. When project management is viewed from the traditional lens of planning, monitoring, and controlling, the human side often goes unnoticed. Matters like teamwork, leadership, communication, cultural diversity, openness of the mind, etc. are gradually gaining momentum to address such aspects of behavioral project management. A rigid mind-set or mental block of project managers increases the threat of scope creep. For example, a project manager’s resistance to say no to the changing demands of clients or top management exposes the project to overrun deadlines. Khushi adds, “As project managers, we don’t want to antagonize relationships with clients and top management. We just keep hoping that things will improve and we will make up—in reality, that never happens.” Project managers with a flexible mind-set can quickly recognize the changing requirements. They can create formal processes with the support of the project sponsor to monitor the progress and initiative changes in project plans (including resource allocation). A flexible mind-set can encourage formal documentation based on revised plans with the concurrence of all related parties to avert scope creep. “It’s not just the project manager’s mind-set; stakeholders’, especially customers’ mind-sets, are equally important,” says Rashi, a project lead in one of India’s largest conglomerates. “Customers often try negotiating with minor changes in scope. If accepted by the project head, they keep improvising at various levels of project delivery. They then start taking the project head as granted. It’s more of an attitudinal problem,” adds Rashi. Similar, could be the case with other vendors and stakeholders. “Changing the scope of project is not an offense. What leads to project failure is appropriate requirements gathering, analysis of changed requirements, documenting the impacts on the project deliverables, and carefully studying the implications,” says Rashi. Project myopia can also encompass myopic project leadership that can lead to scope creep. A weak leadership can lose command of the project. Eventually, others, who are not the decision makers and completely oblivious of the overall plan and its implications, start calling the shots. Often, in such scenarios, by the time higher authorities come to know, it is too late for redressal. Dharit Mehta, an infrastructure project manager, says, “I have come across situations where inflated ego and overconfidence hinders the project manager to initiate discussions with higher authority to salvage project outcomes by revising scope, schedule, and budget.” Can Critical Thinking Help? The invisible thread that connects the various aspects of requirements gathering and analysis to prevent project scope creep is information. However, how can critical thinking help? Most of us feel that critical thinking is just a business jargon—it’s old wine in a new bottle. We all know how to think critically, don’t we? It is about awareness, thinking reasonably with logic, making right
judgments, making correct decisions without biases, and so on and so forth. Then where is the problem? Well, that is not all! Information, knowledge, and thorough processes are like match sticks; unless you light them, there is no fire. Therefore, unless one knows the tools to gainfully use the various facets of critical thinking, it is like a matchstick that gradually attracts moisture. After a while, if not used, it becomes useless. Therefore, it is not about what needs to be done, it is about the mind-set that does it skillfully. Critical thinking can help the project manager to evaluate information and its sources by challenging the project manager’s attitude, traditional assumptions, and beliefs developed from existing contexts and thought processes. As Halpern (2014) defines it, critical thinking is not just a set of cognitive skills and strategies; it is about the attitude to use knowledge and skills to increase the chances of success. In the context of requirements gathering to prevent scope creep in projects, critical thinking can involve the following steps: a. Information gathering: This is the first step in critical thinking. Due to frequent changes in customers’ expectations, stakeholders’ involvements, etc., information generated during project initiation transforms. Changes in information—with respect to the changed requirements—need careful documentation. b. Making sense from information: Making sense implies getting answers to a set of questions: i. What is the extent to which the revised requirements are different from the initial plan? ii. Is this change acceptable and implementable? iii. What would be the impact on project scope, schedule, and budget to incorporate the requirements change(s)? iv. What sanctions from top management are required to initiate this change? v. What are the additional resources required to meet the changed requirements? vi. What are the consequences (from the perspectives of the client, project, and organization) of not accepting the demand for change in requirements? vii. What are the changes in risk-return dynamics to incorporate the changes? viii.Implementing change: Metacognition (i.e., instead of mechanically managing the requirements gathering process) is important in order to be completely aware of the impact of the change on project objectives. This is called metacognition. Some call it mindfulness. Mind mapping can be considered as a corollary to critical thinking. It promotes creativity through graphical illustrations and generates structured thoughts, leading to implementable ideas. IBM has been using mind-mapping techniques for decades to process complex information. For scoping projects, careful usage of the concepts of critical thinking is a prudent way to ensure project success. An open-minded approach to change—critically thinking through the processes, independent of biases and influence of stakeholders, yet respecting the knowledge around that—can help execute the project successfully, and is necessary while implementing change. Segregating Constituents for Requirements Gathering
While requirements gathering and analysis can be critically viewed through collating information, making sense from it, and implementing change, a framework can be developed around it using four pillars of critical thinking: analyze, evaluate, create, and communicate. Analysis is a continuous process that involves detailed inspection of all elements of requirements from the perspective of the project scope. Evaluation helps in assessing the repercussions in quantifiable terms on other units and stakeholders of the project. Dismantling information can help in evaluating every component in detail, and in making valuable judgments. Complex and ambiguous situations force the revisiting of plans and redefining scope statements. After carefully analyzing and evaluating, critical thinking helps in paving the way with a new design mind-set. This is when we create a solution. However, creation is not a one-time job, it is a dynamic concept. All three steps involving analysis, evaluation, and creation remain incomplete if not all stakeholders are congruent in their thought processes. In addition, critical thinking involves a lot of arguments, brainstorming, and discussions among team members. Hence, communication is the bridge that holds the other three facets together. “Redefining project goals by changing initial plans and recreating project deliverables requires adoptability and flexibility, not only from the project manager, but also from the unlimited support of the project team. This requires a high degree of compatibility across levels, problem sharing, and solving together, and an environment that promotes the free flow of information,” asserts Dharit. Let us consider requirements gathering and analysis as an important dimension of project scoping. Documentation needs to be complete, yet precise, for which gathering requirements critically will be necessary. One of the methods of critical thinking is questioning and not being biased with a reply. For instance, consider that an important meeting is scheduled and the project sponsor is asking the team member about the project manager, Vikram. The question is, “Where is Vikram?” There can be varied answers; for example: a. It seems like he is not interested in the meeting; b. She must be late, and that's why she couldn't come; c. Guess he is waiting for the latest update from the client; or d. He is out of town, traveling to Bangalore. The first three responses are biased, assuming things without evidence, though there could be prior occurrences that trigger such assumptions. Answer (d) is closest to reality and captures the fact. In short, critical thinking enables requirements gathering without being biased and judgmental. A meticulous breakdown of four pillars of critical thinking—analyze, evaluate, create, and communicate—can be a response to requirements gathering as an important facet of managing scope creep. Through the Lens of Critical Thinking The devil is in the details; the lens of critical thinking, unless scrupulously dismantled, cannot provide a solution to requirements gathering. The first step is analysis. This would require defining the requirements, based on initial plans with the client and subsequent revisions. It could be crucial to divide these requirements into sections like human resources, technology, machinery, raw materials, inventory, etc., as and when there is a change in the plan, the resource gaps must be identified, and future needs predicted, based on previous patterns, market demand, and expected competition. Of course, the change in requirements has to be
mapped with project’s overall life cycle. Accordingly, revised statements can be prepared and acted upon. Evaluation is an equally important criterion. It entails quantification of requirements enumerated during project initiation and changes thereafter. The exact impact of such quantifications on performance can be assessed by developing measurement yardsticks, depending on the nature of the project, industry dynamics (e.g., an IT project can be different from an infrastructure project), client demand, and delivery constraints. A quick pilot survey to understand the receptiveness of the measurement yardstick to accommodate changing customer requirements can be a smart idea. At this stage, the implications of requirements changes can be evaluated in terms of risk-return trade-off. Analyze: ● ● Define requirements based on clients’ initial and revised plans; Segregate requirements into categories (e.g., human, technology, machinery, raw inputs, etc.); Identify resource gaps and future needs; Analyze how changes in requirements can be accommodated in the project’s overall life cycle; Prepare revised statements for requirements, whenever there is a change in scope. Evaluate: Quantify requirements enumerated during project initiation; Monitor the changes thereafter; Generate measurement yardsticks to determine success and conformance; Perform cost-benefit analysis of deviation of requirements gathering from initial plan; Evaluate risk-return trade-off and implications of requirements change; Evaluate performance measurement tools and their receptiveness to changing customer needs; Create: Create a management information system (MIS) to record and monitor changing requirements; Associate stakeholders who will be impacted (positively and negatively, if at all) by change; Create an iterative process to map revised scope with requirements gathering, subsequent resource requirements and stakeholder involvement, risk-return, impact on cost and budget, and impact on project outcome; Identify change agents for revised requirements; Communicate Communicate the need for requirements gathering and analysis to relevant stakeholders; Enable a two-way communication between the project team and leadership to ensure effective planning, monitoring, and controlling; ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●
● Communicate the creation of MIS, mapping processes for measurement, or other frameworks that define and update requirements to relevant stakeholders; Ensure communication is not mechanical, that it is receptive and acceptable. ● Figure 1: The granular details of critical thinking for requirements gathering In the context of India or other emerging economies, often a politico-hooligan nexus, or a sudden change in host country’s regulatory or socio-economic-political environment, could impinge on a project and potentially torpedo all rigors of the processes as proposed. A risk anticipation and mitigation plan should be put in place to take care of such contingencies, and can be an important constituent of the risk-return trade-off. Figure 2: The critical- thinking framework to requirements gathering Conclusion Analysis and evaluation go hand in hand with creation. It is important to create robust systems and processes that can accommodate changing requirements. A Management Information System (MIS), in this context, can be handy. The MIS should adapt iterative processes to consider the revised scope of requirements gathering and the implications thereafter. It should also be able to produce results on the impact on time and cost and, eventually, project outcome. The change agents who will make all of this happen have to be judiciously engaged. However, such systems would only work if people associated are taken to confidence. All these efforts can go completely wasted if analysis, evaluation, and creation are not communicated to relevant stakeholders. A transparent two-way communication between the project team, project leadership, and top management can facilitate the process and help in effective planning, monitoring, and controlling. For example, before launching the MIS, inputs from the project team, project leadership, and other relevant stakeholders can be integrated into the systems to ensure smooth transition. Remember, such communication can potentially boomerang if mechanically implemented. People around are smart!
Many times, such approaches to requirements gathering to prevent scope creep falls on deaf ears if not mandated from the top. It is important that top management believes in the framework and implements it at the policy level. However, a mandate from the top has the potential to emotionally detach the project team and force them to implement the proposed MIS mechanically. This can turn out to be detrimental. Hence, taking people along can be crucial, while creating the MIS for requirements gathering. In addition, integration across various departments of the organization can be beneficial. This can provide a rich platform for experience sharing and help in creating a learning organization. References 1. Anderson, L. W., Krathwohl, D. R., Airasian, P. W., Cruikshank, K. A., Mayer, R. E., 2. Pintrich, P. R., Raths, J., & Wittrock, M. C. (2001). A taxonomy for learning, teaching and assessing: A revision of Bloom’s taxonomy. New York, NY: Longman Publishing. 3. Artz, A. F., & Armour-Thomas, E. (1992). Development of a cognitive-metacognitive framework for protocol analysis of mathematical problem solving in small groups. Cognition and Instruction, 9(2), 137–175. 4. Halpern, D. F. (2014). Thought and knowledge: An introduction to critical thinking. (5th ed.). New York, NY: Psychology Press. About the Author With a doctorate degree in project risk management, and over 20 years of experience in project management and decision support systems, Vanita Bhoola serves as a professor at S.P. Jain Institute of Management & Research (SPJIMR), Mumbai, India. Apart from teaching at SPJIMR across programs, mentoring students, and publishing in leading international journals, she offers tailored courses across different programs at the Institute and customized executive programs in project management based on company research, sector analysis, and the business environment that influences business. She currently heads the Center for Project Management and Management Development Programs at SPJIMR.