Glossary of terms used by Malotaux with Evo.
Please send comments and suggestions to: niels @

Term Definition Version
Active Synchronisation See Synchronise. 17 Apr 2011
Architect The "conductor" of the orchestra of the product (See Project Manager: conductor of the logistics). Architect is actually a management function: having vision, knowledge and experience of which product to make and how to make it, and creating the result through the minds and hands of others. 1 Feb 2011
Bug, debug A bug is a small creature, autonomously creeping into your product, causing trouble, and you cannot do anything about it. Wrong! People make mistakes and thus cause defects. The words bug and debug are dirty words and should be erased from our dictionary. By actively learning from our mistakes, we can learn to avoid many of them. In Evo, we actively catch our mistakes as early as possible and act upon them. Therefore, the impact of the defects caused by our mistakes is minimised. This leaves a bare minimum of defects at the end of the project. Evo projects do not need a special debugging phase. orig: 2004
25 Mar 2011
CandidateTask A Task that we could consider 1 Feb 2011
CandidateTaskList A List of Tasks that we could consider, listed usually in order of priority 1 Feb 2011
Culture Ingrained customs
Culture is what we learnt by mimicking what we experienced around us: language, social behaviour, faith, religion, folklore, and how these things develop by our social interactions.
1 Feb 2011
Customer The entity that orders our development and pays for it. Because he's paying, the Customer could be interested in a cost/benefit trade-off. Other stakeholders don't pay and may have other priorities. 1 Feb 2011
Debug, debugging Dirty words. Should be scratched from our dictionary. If you want to know how, we can talk about it.
See also bug.
orig: 2004
25 Mar 2011
DeliveryCycle   1 Feb 2011
Defect Cause of a problem experienced by a Stakeholder, ultimately by the Customer.If we use this definition for software, most so called defects aren't defects if about half of the software delivered is never used by any Stakeholder. The only defect is then that this part of the software was made. 1 Feb 2011
Design Design is finding the best compromise between the conflicting requirements and deciding how the product is realized. 1 Feb 2011
DesignLog See DesignLog page. 23 Jan 2015
Developers General description of people who work in development projects. Systems Engineers, Architects, Designers, Programmers, Testers, Project Managers. All those functions that together have to make the development project a success. 1 Feb 2011
Discipline With discipline we don't mean imposed discipline, but rather what you, yourself, know what is best to do. If nobody watches us, it is quite human to cut corners, or to do something else, even if we know this is wrong. We see ourselves doing a less optimal thing and we are unable to discipline ourselves. If somebody watches over our shoulder, keeping discipline is easier. Discipline is difficult, but we can help each other. Evo helps keeping discipline. Why do we want this? Because we enjoy being successful, doing the right things. orig: 2006
17 Apr 2011
Done 100% done. Not to think about it anymore. Only 100% done is done. If 90% is done, we usually still have to do the other 90%. Therefore, done should better be binary: it's either done or not done. 1 Feb 2011
Duration see LeadTime 1 Feb 2011
Effective Producing a desired result with the intended properties 1 Feb 2011
Efficient Producing an effective result economically (with least waste of materials, time, or energy) 1 Feb 2011
Effort The net amount of time to accomplish something 1 Feb 2011
Estimate The tentative or approximate judgement of the numerical value of size, worth, significance or duration of something 1 Feb 2011
FatalDate A hard time limit upon we will deliver what we promised.
 If we do not deliver at the FatalDate we Fail. No finger-pointing to anybody, because we took the responsibility and we didn't deliver. If somebody else was the reason, we could have warned our customer earlier, escalated, or even given back the responsibility. At the FatalDate itself, nobody fails by we ourselves.
1 Feb 2011
Focus Developers tend to be easily distracted by many important or interesting things. Some things may even really be important, however, not at this moment. Keeping focus on the current priority goals, avoiding distractions, is not easy, but saves time. orig: 2006
17 Apr 2011
Goal of a Project Providing the customer with what he needs, at the time he needs it, to be satisfied, and to be more successful than he was without it ... If the customer is not satisfied, he may not want to pay. If he is not successful, he cannot pay. If he is not more successful than he already was, why should he pay anyway? Of course we have to add that what we do in a project is: ... constrained by what the customer can afford and what we mutually beneficially and satisfactorily can deliver in a reasonable period of time. 1 Feb 2011
LeadTime The time between planning a Task and delivering the result 1 Feb 2011
Priority Defining priorities and only working on the highest priorities guides us to doing the most important things first. Priority is 'molded' by many things, see for example the page about Task Selection. orig 2006
17 Apr 2011
ProcessLog   1 Feb 2011
Product A Result, something produced. In the context of this book (which is not about production, but about projects), we use the word product as any result produced by a project. Systems Engineers may use the word System. 1 Feb 2011
Programmer In software projects, programming is the function who transforms the software design into code, which subsequently is turned into computer executable code by a compiler, assembler and/or interpreter. When a person is performing this function, we call him/her a programmer. 1 Feb 2011
Project A planned endeavour with clear start and end conditions, where something not yet well known is done in between. If it's completely well-known, we call it production. 1 Feb 2011
QA   1 Feb 2011
Requirement Requirements are what the Stakeholders require. However, for a project, the requirements are what the project is planning to satisfy. After all, what the Customer wants, he cannot afford. The other Stakeholders, who are not paying, are not interested to trade-off or to compromise, so they would want all they think they want. If the project is trying to satisfy that, it will fail from the beginning. Requirements define what is to be realized, not how it is realized (that is Design). 1 Feb 2011
Result Result is what the Project is produces: the right Result at the Right time, produced efficiently, that is with minimum waste. It is what the Project produces according the Goal of the Project 1 Feb 2011
Risk An event that may cause a Defect. (Others use: An uncertain event that, if it occurs, has a negative effect on project success) 1 Feb 2011
Stakeholder Anybody with a stake in what we are doing. 1 Feb 2011
Synchronise Every project interfaces with the world outside the project. Active synchronisation is needed to make sure that planned dates can be kept. orig 2006
17 Apr 2011
Systems Engineering Producing the right product at the right time to provide the right solution to the right problem even if the problem changes (Thanks Joe Kasser) 1 Feb 2011
Task A defined piece of work to be finished within a certain time 1 Feb 2011
TaskCycle   1 Feb 2011
Tester   1 Feb 2011
TimeBox A TimeBox is the maximum time available for a Task. When the time is up, the Task should be completely done: there is no more time! 2 Feb 2011
TimeLine A technique for controlling longer periods of time.
A line from Now to Then (Then being a defined date!)
1 Feb 2011
User General term for people who (will) use the system we develop. The value of the system only crystallizes when the system is successfully used by the users. Different users may use different parts of the system and use the system differently. The combined user success will determine the value delivered. 1 Feb 2011
Victim Special type of Stakeholder. Is negatively affected by the results of our project. They may want the project to fail and they probably will make the project fail or suffer hard consequences, unless you manage this group of stakeholders appropriately. 1 Feb 2011