Posts
Why UML in CRM? A problem solving perspective
As my basis remains cognitive psychology (I.A. Codoban is the author of this post), it is quite common for me to think about psychological aspects of my IT work and the general IT and CRM domains. One such analogy sprouted out of the reports about failure rates in CRM projects (just see what Gartner and other research groups have to say about this) and problem solving (and decision making, implicitly) theory.
So, this post was born to show a psychological perspective on why using UML for CRM is important.
Problem solving research was born from the need of understanding how people take decisions and which are the risks involved. Economy was and still is one of the fields where such knowledge is applied, but interest domains are expanding. In fact, Herber A. Simon won a Nobel prize for the research and theory about human decision making.
Problem solving is the process of getting from the current to the desired state, with the help of operators that allow to modify things so that we can move from one state to another. It is what happens when the PM calls the team and says: our application needs to be adapted to end-user requirements. We have an initial state of things: the current application, processes, etc. and a desired one, defined abstractly by end-users’ desires and needs. It is also necessary to have the tools and the knowledge needed to modify the application and context, thus to pass from the initial state to another one, and finally to the desired one.
Probably you noticed that in real life things are not always easy - problem solving is not always straight forward ;)
On one side, there is the complexity of the environment that comes with uncertainty, inconsistency, and incomplete information. On the other, there is the human nature expressed in what is called limited rationality. This last concept indicates that there are specific pitfalls for the human mind during the decision and problem solving process.
“ … (the) limits are imposed by the complexity of the world in which we live, the incompleteness and inadequacy of human knowledge, the inconsistencies of individual preference and belief, the conflicts of value among people and groups of people, and the inadequacy of the computations we can carry out, even with the aid of the most powerful computers. The real world of human decisions is not a world of ideal gases, frictionless planes, or vacuums. To bring it within the scope of human thinking powers, we must simplify our problem formulations drastically, even leaving out much or most of what is potentially relevant.” (H.A. Simon and Associates – 1986)
The most common errors have been researched thoroughly, nevertheless it is still difficult to prevent them in applied settings. Just think that there are situations in which people assess the frequency of a class by the ease with which instances can be brought to mind. If you are asked how frequent are names that contain an “R”, research has shown that the answer depends on the number of names that we can recall having that letter.
However, the human mind has managed to “construct” strategies for problem solving that have assured our supremacy as a species, thus it can not be that we mistake to often :) Our mind relies on heuristics and experience in order to facilitate the difficult process and help us reach the goals.
Research has found out the way the process is carried out:
“… problem solving generally proceeds by selective search through large sets of possibilities, using rules of thumb (heuristics) to guide the search. Because the possibilities in realistic problem situations are generally multitudinous, trial-and-error search would simply not work; the search must be highly selective. Chess grandmasters seldom examine more than a hundred of the vast number of possible scenarios that confront them, and similar small numbers of searches are observed in other kinds of problem-solving search.” (H.A. Simon and Associates – 1986)
Expertise comes from experience as the person learns problems, contexts and methods to apply. The famous intuition is due to this knowledge and experience and when it fails it lets the expert with the option of applying the common analysis and inference processes.
“A chess master must be able to recognize about 50,000 different configurations of chess pieces that occur frequently in the course of chess games. A medical diagnostician must be able to recognize tens of thousands of configurations of symptoms; a botanist or zoologist specializing in taxonomy, tens or hundreds of thousands of features of specimens that define their species. For comparison, college graduates typically have vocabularies in their native languages of 50,000 to 200,000 words. (However, these numbers are very small in comparison with the real-world situations the expert faces: there are perhaps 10120 branches in the game tree of chess, a game played with only six kinds of pieces on an 8 x 8 board.)” (H.A. Simon and Associates – 1986)
Real situations are even more complex as they usually refer to complex and ill defined (structured) problems. Classical research examples are the ones of design and engineering domains, where the final desired state is not always clear from the beginning. (It is thus clear that IT is not really in a good position ;)…)
Also, aspects such as setting the agenda and representing the problem, critical issues for problem solving, are still in search of answers and support in applied settings. It can be argued that agenda setting, at least in IT projects, falls under the general Project Management discipline, and thus has achieved certain help through best practices. It should be also said that many CRM projects fail on these aspects as little or no Project Management is involved, and no CRM specific project management methodology exists (at least to our knowledge, please let us know if you are familiar with one).
But let us analyze the representation issue in more detail as we are kicking here a cornerstone for our discourse about UML and CRM.
“The way in which problems are represented has much to do with the quality of the solutions that are found.” (H.A. Simon and Associates – 1986)
Many authors have argued that problem solving is not an entirely mental process but need and relies on real manipulations as well. (This reminds me of my math teacher that desperately tried to construct 3D models of geometrical problems in order to facilitate understanding.) The physical interaction process is important for constructing knowledge as it allows trial-and-error behavior with direct feedback and assures that the mistakes are never afterwards repeated. It seems obvious that our mind is prone to learn better from direct experience than just mental fantasy… (Langley and Rogers argue in this sense, but there are numerous other authors that agree).
Using models (simplified representations of reality) helps our mind in its tasks, as it reduces the information to the most relevant one (if the model is constructed well) but also allows certain manipulations without the problems of real situations, such as dead-ends (if we use supports for our models, of course, and not just our fantasy).
Here is the right moment to ask: why are we talking about UML in CRM? Or, rather, why are we adepts of UML in CRM?
Well, one point of viewing a CRM IT project is that of a problem-solving process, and as such it is prone to certain errors and needs certain supports in order to reach de desired objective (in the desired way). In fact, it is linked with the general decision making process present in our everyday lives. This is a complex setting for problem-solving with various actors involved, strategic and tactical hidden processes, and complex unstructured problems at different levels.
UML (Unified Modeling Language) is and important basis for creating models especially for the IT environment and it also supports the software creation process from requirements gathering to testing and deployment. UML is a standardized general-purpose modeling language that includes a graphical notation used to create an abstract model of a system. UML is an easy and graphical way of representing all that is needed in a software project with specific support for different phases or concepts. Moreover, UML is a methodology itself, guiding and helping the practitioner.
UML use cases are a good example for requirements gathering and analysis, and many business analysis books indicate them as the best solution to form a base for the project. The strength of UML lies not only in the easy graphical representation, but also in his semantics and extension possibilities.
The usage of UML in CRM projects can bring a lot of benefits, not only from a technical point of view, but also from a cognitive one. Although not extensive, here are some points about the usefulness of UML for CRM projects problem solving, related to the above introduction.
First of all, UML allows the representation of the problem and of its space. As a special modeling language for IT environments, UML is particularly suited for modeling and supporting the development process. Use cases are usually involved in requirements gathering and analysis, as they are visual representation of end-user requirements and easily understandable by all the involved actors. The fact that everybody can grasp their meaning makes use cases a suited support for negotiating changes and functionalities in the application. They can also be used for explaining to the end-users and non-technical stakeholders, reasons for certain prioritizations and planning. In this way, everybody understands the decisions taken and forms correct expectations of the future evolution.
But also the application can be modeled with UML: by this the team can rely on a common documented vision of how the system is and how it works. It also facilitates the conceptualization and analysis of new requirements as it provides for a frame in which they need to be integrated.
Thus, on the one hand, with the help of UML we can define the current situation (at least in terms of the application) and sketch the desired state based on requirements.
We have mentioned before that one important characteristics of an expert is her experience in the field. Nevertheless, experts are quite hard to find and not easy to retain. (Moreover, the problem domain definition might even change from one project to the other, based on the customizations implemented and the organizational policies and processes, thus the definition of an expert is project-related). By documenting the application, the requirements and subsequent evolutions in a visual way, UML assures that the correct and absolutely needed knowledge is created and maintained. It will then be easier for all the members of the team to take decisions being informed about the application.
The UML documentation of requirements and solutions act as a best practices repository that offers a background for future problems and solutions in terms not only of end products but also processes (how the solution was reached). This is also an expert-level type of support, as it is no longer needed to be present in a project from the beginning in order not to repeat the same errors. It is enough to go over the simple documentation and understand the essays already made and the solutions finally implemented. The repository is available (and accessible in terms of knowledge) to all the stakeholders enabling the creation of shared knowledge (and its documentation) and facilitating decision making process. Also, the complex group decision situation is enhanced through a common understanding of the problem at hand.
With the right models available, estimating the time needed for implementing the requirements is more straightforward, thus helping agenda creation and priority lists.
One of the best aspects is, though, the possibility of experimenting in the model world during the problem-solving process. Above, we introduced the importance of making changes to the problem and its context not only mentally. UML modeling allows externalization and manipulation while still not having an impact on the final application, nevertheless allowing evaluation and analysis.
All these cognitive advantages can come as a help during a CRM project, and hinder its failures.
Although there is a lot to be said about problem solving (as well as UML in CRM), this post is just an introduction meant to enlarge the perspective of the reader, and not a comprehensive theory. In order to facilitate the usage of UML in the particular CRM context, we have developed an extension of the classical concepts for modeling that cover also the CRM field, as well as models of specific CRM applications (more information). These last developments can be very useful in analyzing customized applications and understanding the changes that have been implemented in order to identify possible problems and improvement possibilities.
There are several other reasons for why UML is important in CRM, but this post is already long enough :)
We are going to go into more details about UML in CRM and about our ideas regarding CRM project management methodologies in future posts.
For further information and UML-CRM related services contact us at: manuelbreschi@bluebottle.com
So, this post was born to show a psychological perspective on why using UML for CRM is important.
Problem solving research was born from the need of understanding how people take decisions and which are the risks involved. Economy was and still is one of the fields where such knowledge is applied, but interest domains are expanding. In fact, Herber A. Simon won a Nobel prize for the research and theory about human decision making.
Problem solving is the process of getting from the current to the desired state, with the help of operators that allow to modify things so that we can move from one state to another. It is what happens when the PM calls the team and says: our application needs to be adapted to end-user requirements. We have an initial state of things: the current application, processes, etc. and a desired one, defined abstractly by end-users’ desires and needs. It is also necessary to have the tools and the knowledge needed to modify the application and context, thus to pass from the initial state to another one, and finally to the desired one.
Probably you noticed that in real life things are not always easy - problem solving is not always straight forward ;)
On one side, there is the complexity of the environment that comes with uncertainty, inconsistency, and incomplete information. On the other, there is the human nature expressed in what is called limited rationality. This last concept indicates that there are specific pitfalls for the human mind during the decision and problem solving process.
“ … (the) limits are imposed by the complexity of the world in which we live, the incompleteness and inadequacy of human knowledge, the inconsistencies of individual preference and belief, the conflicts of value among people and groups of people, and the inadequacy of the computations we can carry out, even with the aid of the most powerful computers. The real world of human decisions is not a world of ideal gases, frictionless planes, or vacuums. To bring it within the scope of human thinking powers, we must simplify our problem formulations drastically, even leaving out much or most of what is potentially relevant.” (H.A. Simon and Associates – 1986)
The most common errors have been researched thoroughly, nevertheless it is still difficult to prevent them in applied settings. Just think that there are situations in which people assess the frequency of a class by the ease with which instances can be brought to mind. If you are asked how frequent are names that contain an “R”, research has shown that the answer depends on the number of names that we can recall having that letter.
However, the human mind has managed to “construct” strategies for problem solving that have assured our supremacy as a species, thus it can not be that we mistake to often :) Our mind relies on heuristics and experience in order to facilitate the difficult process and help us reach the goals.
Research has found out the way the process is carried out:
“… problem solving generally proceeds by selective search through large sets of possibilities, using rules of thumb (heuristics) to guide the search. Because the possibilities in realistic problem situations are generally multitudinous, trial-and-error search would simply not work; the search must be highly selective. Chess grandmasters seldom examine more than a hundred of the vast number of possible scenarios that confront them, and similar small numbers of searches are observed in other kinds of problem-solving search.” (H.A. Simon and Associates – 1986)
Expertise comes from experience as the person learns problems, contexts and methods to apply. The famous intuition is due to this knowledge and experience and when it fails it lets the expert with the option of applying the common analysis and inference processes.
“A chess master must be able to recognize about 50,000 different configurations of chess pieces that occur frequently in the course of chess games. A medical diagnostician must be able to recognize tens of thousands of configurations of symptoms; a botanist or zoologist specializing in taxonomy, tens or hundreds of thousands of features of specimens that define their species. For comparison, college graduates typically have vocabularies in their native languages of 50,000 to 200,000 words. (However, these numbers are very small in comparison with the real-world situations the expert faces: there are perhaps 10120 branches in the game tree of chess, a game played with only six kinds of pieces on an 8 x 8 board.)” (H.A. Simon and Associates – 1986)
Real situations are even more complex as they usually refer to complex and ill defined (structured) problems. Classical research examples are the ones of design and engineering domains, where the final desired state is not always clear from the beginning. (It is thus clear that IT is not really in a good position ;)…)
Also, aspects such as setting the agenda and representing the problem, critical issues for problem solving, are still in search of answers and support in applied settings. It can be argued that agenda setting, at least in IT projects, falls under the general Project Management discipline, and thus has achieved certain help through best practices. It should be also said that many CRM projects fail on these aspects as little or no Project Management is involved, and no CRM specific project management methodology exists (at least to our knowledge, please let us know if you are familiar with one).
But let us analyze the representation issue in more detail as we are kicking here a cornerstone for our discourse about UML and CRM.
“The way in which problems are represented has much to do with the quality of the solutions that are found.” (H.A. Simon and Associates – 1986)
Many authors have argued that problem solving is not an entirely mental process but need and relies on real manipulations as well. (This reminds me of my math teacher that desperately tried to construct 3D models of geometrical problems in order to facilitate understanding.) The physical interaction process is important for constructing knowledge as it allows trial-and-error behavior with direct feedback and assures that the mistakes are never afterwards repeated. It seems obvious that our mind is prone to learn better from direct experience than just mental fantasy… (Langley and Rogers argue in this sense, but there are numerous other authors that agree).
Using models (simplified representations of reality) helps our mind in its tasks, as it reduces the information to the most relevant one (if the model is constructed well) but also allows certain manipulations without the problems of real situations, such as dead-ends (if we use supports for our models, of course, and not just our fantasy).
Here is the right moment to ask: why are we talking about UML in CRM? Or, rather, why are we adepts of UML in CRM?
Well, one point of viewing a CRM IT project is that of a problem-solving process, and as such it is prone to certain errors and needs certain supports in order to reach de desired objective (in the desired way). In fact, it is linked with the general decision making process present in our everyday lives. This is a complex setting for problem-solving with various actors involved, strategic and tactical hidden processes, and complex unstructured problems at different levels.
UML (Unified Modeling Language) is and important basis for creating models especially for the IT environment and it also supports the software creation process from requirements gathering to testing and deployment. UML is a standardized general-purpose modeling language that includes a graphical notation used to create an abstract model of a system. UML is an easy and graphical way of representing all that is needed in a software project with specific support for different phases or concepts. Moreover, UML is a methodology itself, guiding and helping the practitioner.
UML use cases are a good example for requirements gathering and analysis, and many business analysis books indicate them as the best solution to form a base for the project. The strength of UML lies not only in the easy graphical representation, but also in his semantics and extension possibilities.
The usage of UML in CRM projects can bring a lot of benefits, not only from a technical point of view, but also from a cognitive one. Although not extensive, here are some points about the usefulness of UML for CRM projects problem solving, related to the above introduction.
First of all, UML allows the representation of the problem and of its space. As a special modeling language for IT environments, UML is particularly suited for modeling and supporting the development process. Use cases are usually involved in requirements gathering and analysis, as they are visual representation of end-user requirements and easily understandable by all the involved actors. The fact that everybody can grasp their meaning makes use cases a suited support for negotiating changes and functionalities in the application. They can also be used for explaining to the end-users and non-technical stakeholders, reasons for certain prioritizations and planning. In this way, everybody understands the decisions taken and forms correct expectations of the future evolution.
But also the application can be modeled with UML: by this the team can rely on a common documented vision of how the system is and how it works. It also facilitates the conceptualization and analysis of new requirements as it provides for a frame in which they need to be integrated.
Thus, on the one hand, with the help of UML we can define the current situation (at least in terms of the application) and sketch the desired state based on requirements.
We have mentioned before that one important characteristics of an expert is her experience in the field. Nevertheless, experts are quite hard to find and not easy to retain. (Moreover, the problem domain definition might even change from one project to the other, based on the customizations implemented and the organizational policies and processes, thus the definition of an expert is project-related). By documenting the application, the requirements and subsequent evolutions in a visual way, UML assures that the correct and absolutely needed knowledge is created and maintained. It will then be easier for all the members of the team to take decisions being informed about the application.
The UML documentation of requirements and solutions act as a best practices repository that offers a background for future problems and solutions in terms not only of end products but also processes (how the solution was reached). This is also an expert-level type of support, as it is no longer needed to be present in a project from the beginning in order not to repeat the same errors. It is enough to go over the simple documentation and understand the essays already made and the solutions finally implemented. The repository is available (and accessible in terms of knowledge) to all the stakeholders enabling the creation of shared knowledge (and its documentation) and facilitating decision making process. Also, the complex group decision situation is enhanced through a common understanding of the problem at hand.
With the right models available, estimating the time needed for implementing the requirements is more straightforward, thus helping agenda creation and priority lists.
One of the best aspects is, though, the possibility of experimenting in the model world during the problem-solving process. Above, we introduced the importance of making changes to the problem and its context not only mentally. UML modeling allows externalization and manipulation while still not having an impact on the final application, nevertheless allowing evaluation and analysis.
All these cognitive advantages can come as a help during a CRM project, and hinder its failures.
Although there is a lot to be said about problem solving (as well as UML in CRM), this post is just an introduction meant to enlarge the perspective of the reader, and not a comprehensive theory. In order to facilitate the usage of UML in the particular CRM context, we have developed an extension of the classical concepts for modeling that cover also the CRM field, as well as models of specific CRM applications (more information). These last developments can be very useful in analyzing customized applications and understanding the changes that have been implemented in order to identify possible problems and improvement possibilities.
There are several other reasons for why UML is important in CRM, but this post is already long enough :)
We are going to go into more details about UML in CRM and about our ideas regarding CRM project management methodologies in future posts.
For further information and UML-CRM related services contact us at: manuelbreschi@bluebottle.com
0 commenti:
Post a Comment