Why does range contagion happen so often? what should be done to manage the scope?
Scope sprawl is often defined as an unplanned project size. if we analyze the root cause of scope contagion, we can identify the following major problems:
01. The process is misdefined and does not realize that all processes are interconnected.
these questions are not about the work we've done, they're about what we haven't done. all problems begin with how organizations define business processes.
when asked how business processes are defined, i often get answers that it is a set of business activities that turn input into production results.
processes are rarely mentioned in two characteristics: first, almost all processes are cross-functional. second, almost all processes are interconnected. if one of the "processes" in your project contains only one function, it is highly likely that your original project scope would contain only part of the process, and at the end of the day, the project scope would contain the entire process.
2. The wrong person in the definition range
the second reason for the spread of process improvement project scope is that we don't often have the right members to define processes.
members must be senior managers in the relevant functions and have a very comprehensive understanding of the business and the problems. defining the boundaries of a process is the responsibility of these members.
for example, determine where the process starts and ends. these team members must also have the right to mobilize resources. in case the project boundaries are defined, but the resources required for the project cannot be found.
let's take a look at the order management process improvement project.
does this process begin with the phone ringing? or start with signing a bill? or does it begin with credit being recognized and the validity of the product being confirmed? when does the process end? does it end at shipped or end with product delivery or product acceptance?
the way we define project boundaries affects the project itself again and again. this affects who we get input from, who our core team should include, what we want to measure, how we set up our vision, and what range changes should be included when we redesign or improve the process.
when the scope is defined by the right team, the team can also guarantee access to resources. don't let anyone else do your job, which will spread the scope to take advantage of.
03. Terms related to the project are not defined
we must discuss project-related terminology in order for all project participants and process parties to agree on the meaning of the term. most of the time, we "assume" that everyone's understanding of the process is consistent, one of the many "assumptions" in the process project process that are often inaccurate.
while we assume that everyone has a clear understanding of the process and the terminology used in the process, the unfortunate thing is that these assumptions are mere assumptions, not facts. it is only when we go deep into the project and begin to question and reflect that we can define these terms precisely.
often, the definition of a term also changes the definition of the project. for example, when it comes to American pizza, we have a very clear picture in mind. but if you order a pizza in italy, hungary or another country, it's likely to be a very novel rectangular-like pizza, with some with omelettes and corn on top.
This suggests that we cannot assume that everyone understands the terminology used in the project. For accounting, for example, Fas by should be the FASB, but if you weren't an accountant, you wouldn't understand the pun and might think it was just a dog's name.
04. There is no definition of a high-level interface between processes
High-level interfaces between processes must be defined, and to do so, it is important to know what the process is considering for the project and what the interface between the process and other processes is. In other words, which processes affect the process, or are affected by the process, what creates the interface, or what flows between the process and other stakeholders. We define these interfaces as IGOEs (input, dominate, output, enable).
often, it is difficult for an organization to define these interfaces because they do not even define the process itself.
therefore, if an organization does not define its processes, how can the scope of the project be determined? typically, there are many organizational functional modules involved in the project, which suggests that we were aware from the outset that scope would spread (lack of an accurate process definition). therefore, we need to define some high-level process interfaces.
so how long does it take to define a high-level process? our project time is limited and we can't spend too much time on things that are not directly related to the project. experience is available, and if the right people are in the meeting room, the work can be done easily in half a day.
it's worth investing time in defining high-level processes from the start, which ensures that you know where the process improvement project is in this big flowchart.
the real value of a large flowchart is that we can use it all the time, and when we know all the process interfaces, we do what we call scope analysis.
5. Ignored these sub-interface "medical examination" work
we need to analyze all interfaces to make sure that each is intact. the aim is to focus our energies on what really matters and to really know what can and can't be affected. to do this, we must ask some questions: which works well and what doesn't? what is impossible to change? what consumes a lot of our time within a given resource and time constraint?
the result of this new understanding is a change in scope. this means that everything contained in the boundary is likely to change in some way. this is our project scope definition.
06. Not aware of the problem that certain aspects of the project can make the project too large to manage.
we must take the reality into account in the scope of the project. for example, if the scope of the project is a payment process for a large financial institution, we need to consider whether to examine all payment categories or only a few major payment categories that have the greatest impact on the organization's risk and expectations.
in short, can the scope of the project be better managed? of course! the frustration of a process improvement project is often caused by not knowing how to handle project scope issues. you now have the knowledge, the ability to control your project efficiently and effectively!
No comments:
Post a Comment