Learning is one of three major pillars in a Software Engineering project. The other two are product integrity and process integrity. Knowledge is an intangible asset, necessary to build a software product, and represented in other engineering disciplines by equations, text books, images and data. Knowledge is commonly represented in software as source code with defined semantics and syntax. There are other ways to represent knowledge in a software project, such as requirements, source code comments, specifications, peer reviews, test cases and results, to mention the most common.

Few would probably admit it, but the state of a software project can be really elusive for long periods of its execution. The situation is mostly critical early on, when concepts are floating around and there is no real agreement on what should be built, and when minor corrections to how the project should be executed can have real impact. Project Managers use direct reports as a standard approach to obtain information about the state of a project. Subordinates on their side minimise problems in the hope that they will be solved later on. Direct reports have seldom real data to backup their claims, and the whole thing can turn into an exercise of opacity and subtle deception. Objective data is seldom produced until bug reports start to drop in, and then it's usually too late to correct the situation. Lacking information on the state of a project early on will more often than not result in unnecessary and costly rework.

If learning is so crucial in a project, how is it represented and how can it be measured? Both the rate and quality of learning is important in product development. The type of learning is usually separated into problem-learning and solution-learning, where problem-learning is the most important. The solution-learning should never be the top priority for a Project Manager, since it's mainly about source code development and failed test cases which will turn up relatively late in a project. One way to measure problem-learning is to look at produced work from elicitation activities, from the specification of requirements and from made peer reviews. Because the output from elicitation activities act as input to requirements writing and modelling activities, the state of specified requirements can be used as congruent data. The rate of learning is largely connected to the process integrity and answers the questions how well the process is followed and supports performed work. The learning-rate is most critical in the beginning of a project. Projects who have problems with their learning-quality will produce products of low quality; which is the topic of product integrity.

Defined metrics must be based on a sound theoretical framework that supports communication and understanding, key concepts in product development. For rCoach One, the metrics are based on linguistics and grammar; metrics that promote "good writing" and thereby cognition.