Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 1

Exemplifying Mental Model

Shailendra Malik

When a child cries out loud and mother feeds him, he feels satisfied and goes back to sleep or starts playing. He
does that again and process repeats many times. In so doing, child develops a mental model that by crying his
hunger would be satisfied. On the other hand, mother develops a mental model that child is crying because he is
hungry. So unknowingly, based upon prejudice, a mental model is under development in the situation.
Craik mentioned the term Mental Model for the first time in his book The Nature of Explanations. A Mental
Model is a learned set of rules about how world looks. Mental models are a set of assumptions, generalizations or
even images that influence the way we understand the world. They are like Stereotypes.
Mental models are very prevalent and easily identifiable at organization. Sarthak was a Software Engineering
Manager at BankSoft Solutions, and delivering the product with high quality was his high priority goal. With so
much talk on Quality he was always trying to challenge himself as what can he do to improve the ongoing process
and meet his goal and if possible go beyond that. With this thought in mind, he had frequent meetings with team,
which was a mix of Generation X and Y people, and figured that no one was sure on how much Quality was
demanded by customer. Quality sounded so much qualitative to everyone that its actual meaning blurred. Sarthak
realized that unless hequantifies the term Quality, he will never be able to claim the degree to which his product
meets the customers requirement. He started thinking of revising the Entry and Exit criteria for his project, which
were very subjective, like deliver a high quality product meeting all the customer requirements and defects should
be within an acceptable range. He shifted his focus on having User Acceptance Test (UAT) Cases instead, where
with the inception of project customer would have to supply a set of acceptance test cases on the basis of which a
final product will be accepted or rejected. By doing this, he believed the development of software would be
acceptance driven and all the team members would know directly the customers requirements. He executed a
pilot project by asking couple of team members to work on this model for a small utility they created to automate
some of the manual work they were doing daily; it was found highly effective and everyone in the team liked the
approach. Riding on the wave of enthusiasm, Sarthak went to meet his Delivery Manager and proposed him the
approach that we should ask customer to provide UAT at the time of inception of the project and should also
revise the contract. Sarthak believed that Quality is a shared responsibility of customer and vendor. His Delivery
Manager, Prasad, with 30 years of experience in software industry, found himself in disagreement with what
Sarthak was proposing. Prasad said, throughout his career no customer has ever provided UAT and if we go back to
customer asking for it and even revising the contract, the entire relationship might go into jeopardy. Prasad
believed that asking customer for UAT sounds like shifting the risk to other side and customer will not take that
positively. Prasad said if customer is to write UAT then what our Quality team is doing, Sarthak said they are
nowhere close to business and they see the product through set of documents not in reality unlike the customer
and this is where the difference is. Prasad did not approve the approach and Sarthak came back empty handed.
Sarthak was a firm believer of doing the same things differently; he changed his approach and shared this idea
directly with the customer. Sarthak knew what is doing is not aligned with this Boss thought but he saw a big value
in this for all the stakeholder and he knew once customer approves it his Boss would agree for sure that he was
confident of. Customer was elated about the idea and he wondered why none of them thought of doing it earlier.
Customer took it as he has been offered to play an active role in software development and by doing this he can
help big time in defect prevention and overall turnaround time of defect removal will be much less. Customer
approved the idea and the project met all the software metrics and went beyond expectation for some of the
metrics like Post Deliver Defect and Defect Removal Efficiency. Prasad also aligned himself, at a very later stage, to
the idea and asked Sarthak to showcase his idea in other business units and institutionalize this process. Sarthak
challenged his mental model, Prasad stuck to it; difference was obvious.
As we can see from the above, mental models obscure the potential threat at times but challenging them also
shows you the opportunities. Mental models work as barrier for innovation and hence they interrupt the
transformation of learning. We need to learn to reduce our mental models to keep only those which can help us
increase our knowledge. We need to find a balance between two stages, excess of either could be challenging.

You might also like