The devil in the detail

When writing a quality system manual there is (at least should be) a need to talk about real-world objects. Let’s call them primary objects for lack of a better word. Examples are a product or a (software) bug (whether a bug is an “object” is of course also debatable but in the abstract world of software it is). Sometimes we on the other hand need to refer to some kind of representation Continue Reading

This is not quality

We all know that market economy is not perfect but that the alternatives are worse. Right now I’m trying to wrap my brain around the fact that there are companies that seem to survive in a market economy despite apparent disregard for their customers. The example I currently have on my mind is CanalDigital, a Swedish satellite TV provider. They have a habit of calling their customers offering additional channels and other Continue Reading

Trust, transparency and Toyota

A recent article in The Economist [1] ascribed some of the economic and social success of the Nordic countries to a high level of trust. In the period of large-scale emigration of Swedes to America, they came to be known as “dumb Swedes” in the new country because their high level of trust in people. Today the descendants of these dumb Swedes still have higher that average trust in their fellow citizens Continue Reading

Product, not project – part 2

Something caught my eye yesterday when I helped my son to get started with Code::Blocks, a light-weight integrated software development environment (IDE): in all IDEs that I’ve worked with lately (Eclipse, Visual Studio and Code::Blocks) the collection of source code and other files is collective called “project”. This may seem like an unimportant little observation but again I believe that using the right term is important for people’s mental models of what’s Continue Reading

Managing products

In an earlier post I wrote about the difference between a project and a product. This distinction may seem obvious for some but considering the number of times I’ve found myself discussing its implications I’ve come to the conclusion that it may not be all that obvious. Many traditional development process descriptions start with a requirements specification of some kind and then go on describing the creation of the rest of the Continue Reading

When do we need a project?

The project format is often the default way of organizing product development. Many organizations have elaborate processes for managing projects such as the UK Government’s PRINCE2 and Ericsson’s PROPS. Both are examples of the Stage-Gate process referred to in an earlier post. Sometimes the project format is warranted, sometimes it is not. I came to think of a rather old paper of which I have faded photo copy in my (physical) binder Continue Reading

Product, not project

The system development project is often used as the area of interest or scope when talking about processes, documents, maturity etc. Some concrete examples are: The CMMI maturity level 2 is achieved by defining a process for each project. A configuration management plan is often suggested to be written per project. Repositories for information items such as change requests and source code files are often set up per project. I’m speculating a Continue Reading

Test driving an organization

Reorganizations are probably as old as humanity. The paleolithic hunting parties must have been subject to reorganizations from time to time. It might have been a bit more physical than the garden variety reorganization today, but the objective was probably similar: to make the organization more effective and efficient or to reflect a new power structure. Reorganizations are not always easy. I have a couple of times used a rather simple verification Continue Reading

A false dichotomy

I often hear expressions such as “here we should define what we do, not how we do it”. These kinds of statements are in my opinion rather meaningless or at least ill-defined. Let’s take an example from the quality management domain. Some level of process or method description may be said to describe “what” (to do), not “how” (to do it). Typically a process description tells you to do, say, A, B Continue Reading

How to create and manage a useful operations manual

In the very first post on this blog I talked about operations manuals, i.e. descriptions of the prescribed or recommended way of working in an engineering organization. I fully acknowledge that very few people find this topic particularly exciting. Some knowledge management folks I talk to consider operations manuals a failed concept to start with. It’s all in the heads of the people they say. Some slide-ware-wielding types on the other hand Continue Reading