Archive for the 'Quality' Category

Published by Arto Jarvinen on 14 Aug 2015

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 of that primary object like a ticket in a bug tracking system (representing a real-world bug). Let’s call these objects meta-objects as they contain information about primary objects. Sometimes this causes no problems like when we have a product and a product specification describing the product. (The product specification is of course also a real-world object but it is not “primary” in the sense that it doesn’t have any justification without the primary object it describes.) In this case the objects have different names (“product” and “product specification”) and will not be confused.

Sometimes it is very convenient to use the same name for the primary object and its meta-object though. When for instance modeling a system in a UML tool, the modeler may describe real-world, primary use cases with meta-objects of the type use case in the tool. When we refer to “use case” in the quality system manual for such an organization, we don’t know whether we refer to the primary use case or its representation in the tool, the meta-use case. Many times this ambiguity goes unnoticed. The text may apply reasonably well to both objects. Sometimes we are able to infer from the text to which object it refers. But sometimes we may have a slightly larger ambiguity. Let’s say that we are developing a medical device and wish to manage the clinical risks potentially caused by the device. Let’s also assume that we have a tool for documenting and tracking individual clinical risks. When we in the quality system manual write “find all clinical risks” we can’t be sure if we are referring to the clinical risks already documented as records in the tool or if we are referring to previously unknown primary clinical risks. The editor of the quality system manual will also invariable go astray from time to time and describe the primary object when a description of the meta-object was called for, and sometimes vice versa. A primary use case is after all a rather different animal than the meta-use case in the tool.

It might be a little clunky to come up with different names for the primary objects and the meta-objects. What would we for instance call the use case meta-objects? “Meta-use case” doesn’t roll so easily off the tongue. I have therefore adapted a convention according to which all primary objects are denoted with all lower-case letters and the meta-objects with capitalized names.

This may not be a Nobel winning insight but I’ve seen confusion about this many times, and I have been confused myself, so I still wanted to share it.

Published by Arto Jarvinen on 07 Jul 2015

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 products. Each and every time they have called me I have told them to take me off their calling lists since I hate wasting my time on such calls and I never buy anything during an unsolicited phone call. I probably asked about five times before I mailed CanalDigital’s customer support making the same request. I told them that I would cancel my subscription if they didn’t stop harassing me over the phone. They promised to take me off the lists. A few weeks later I got a call from – you guessed it – CanalDigital. I might have lost my temper a bit on some poor innocent student trying to make some extra money at a call center.

I wrote to customer support again telling them that they obviously hadn’t taken me off the lists after all and that I now therefore wanted to cancel my subscription. The answer I got was a simple: “We have received your cancellation. We will process it shortly.” No explanations, no excuses.

After a couple of weeks I got a call from – CanalDigital. For a second I thought that maybe a manager had heard of this and wanted to make things right. But no, it was a an unfortunate call center temp who wanted to talk about a special offer for a “faithful customer”. Kafka couldn’t have written CanalDigital’s sales manual better and there is some humor in this.

I can’t understand however hard I try that a company like CanalDigital can get away with this. I’m also confused about the purpose of harassing customers until they can’t take it anymore. Or am I a very odd customer who doesn’t want unsolicited phone calls at random hours?

I got a partial explanation a bit later. There was a person calling from customer support wanting to confirm my cancellation. I again tried, helpful as I am by nature, to explain the reason for my cancellation. He was not the least interested but instead offered me the explanation that the call center staff was not really employed by CanalDigital, meaning that CanalDigital couldn’t really be held responsible for their behavior. Maybe the customer support isn’t employed by CanalDigital either.

I confirmed my cancellation.

Edit: There were more calls from CanalDigital. I complained again. They promised to take me off all the list this time. Yesterday there was a new call. There was even a call to my daughter who doesn’t have anything to do with this except that I used to own her phone subscription. I tried to take the complaint to an arbitration organization, Telekområdgivarna. It turned out that CanalDigital is not a member. Figures.

Published by Arto Jarvinen on 16 Mar 2013

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 and tend to live in rather well-run states such as Minnesota.

It is possible to have relatively high taxes (such as in Minnesota or Sweden) if people trust that taxes are used for good purposes. Trust in the Nordic countries emanate from many sources but transparency is a major one. It is not easy to embezzle public funds when all records are public and subject to the scrutiny of the press and of curious citizens.

I claim that the same goes for corporations. With a high level of trust between employees, departments, country organizations etc the transaction costs can be low. Transaction costs in a corporate setting are typically different types of follow-up and reporting procedures, elaborate internal pricing schemes, and in more extreme cases, turf wars.

A car and a process you can trust.

A typical scenario is that when a particular problem area catches the eye of a particular manager (or a group of managers) who doesn’t entirely trust the organization’s ability to handle the problem then they feel the natural, and in this situation perfectly responsible, need to alleviate their uncertainty by starting to make inquiries. If the situation gets more serious the managers start requiring extra (ad-hoc) reporting on the progress of the resolution of the problem or feel that they need to put together a “tiger team” to expedite the resolution process.

Despite superficial similarities, the above behavior is the antithesis of the Toyota Production System where managers likewise come running when there is a problem. But unlike in the scene described above, they don’t come running to expedite the process, they come running to help solving the root cause of the disturbance.

The extra reporting, the extra phone calls, the extra emails etc are all caused by the lack of trust in the process and add little value to the actual problem resolution process. They in fact make the process less efficient. A “tiger team” furthermore masks any deficiencies in the regular process by effectively bypassing it, preventing the organization from addressing the root cause of the lack of trust.

The explicit goal of building trust has not afaik been on the top of any process improvement models. Many models do result in higher trust when successfully implemented but I believe more explicit actions can be taken to improve trust faster. Some such actions could be:

  • Make all processes extremely transparent; make it easy for anybody to see the backlogs and progress of every department. This facilitates the Genchi Genbutsu, “go and see”, of the Toyota Production System, an attitude that helps managers to stay informed about what’s going on in the organization on a continuous basis.
  • When the organization is more mature, make metrics about performance visible for everyone.
  • Make decisions and their rationales visible.
  • When communicating about your area of responsibilities, make sure that you are well read. When uncertain, state this and the reason for the uncertainty.
  • State clearly who’s responsible for what. If nobody steps forward and clearly takes charge of an issue, then uncertainty thrives.

Last but not least: do a good job (and make it known to others that you did a good job)!


[1] The secret of their success.

Published by Arto Jarvinen on 04 Dec 2012

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 going on. A “project” is something temporary while a “product” would be something rather more persistent. I would have suggested the “product” word here instead. See also my earlier post on this topic.

Published by Arto Jarvinen on 29 Oct 2012

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 development artifacts, all the way to a verified, validated and released product. In contrast to such one-off, linear processes, most system development organizations are almost completely occupied with continuously upgrading and correcting existing products based on a steady stream of internal ideas and new requirements and wants from customers, distributors and other external stakeholders. The upgrades are typically indicated by the version number of the product. (I’m for instance writing this on a computer running Ubuntu 12.04 which is an upgrade from Ubuntu 11.10 and so on.)

For such more or less continuous product development clearly something else is needed than a one-off development process to guide the engineering efforts. We need to plan several (upgrade) projects ahead to secure the necessary resources and for communicating with the market. We also need to continuously decide exactly what new features and corrections to add to the product at each upgrade.

Enter product management (and say hello to the product manager).

A product is according to Wikipedia “anything that can be offered to a market that might satisfy a want or need”. To maximize profits we want to make sure that a product matches the “wants or needs” as well as possible at the right price. Not only do we need to react to the feedback from existing customers and other stakeholders, we also need to pro-actively add innovative (and some not so innovative) new features so as to maximize profits, market share or whatever our goal might be for the moment.

To handle both the short-term requests from existing customers, sales etc and to actively manage the products features in the medium and long term is the purpose of product management and the ultimate responsibility of the product manager.

To plan and communicate the overall contents and timing of the major upgrades of the product, the product manager creates and maintains a product plan (aka product road-map) that in turn is based on both ad-hoc input from the market and thorough analyses of the targeted market segments, societal trends, the competition, available and future technology, partners etc (see e.g. [1]). All this makes the product manager one of the most important roles in the company, if not the most important role, and product management perhaps the most important process in the company.

Since we need to manage each product over its entire life-cycle, product management is not (and I’m sorry for keeping repeating myself) a one-shot project activity but a recurring line activity. The figure below gives a simplified view of how product management can be integrated into a project-oriented organization.

Product Management
Continuous product management.

Each new suggested feature, whether a new function requested by a customer or a feature suggested internally by the project manager, system architect or somebody else, is described in a change request.

New change requests are regularly evaluated by a change control board (CCB) with respect to cost / benefit and their consistency with the overall product plan. If the benefit exceeds the cost and the suggested new feature is in line with the product plan, then the change request is accepted for implementation and at some point scheduled into a project. Otherwise the change request is rejected.

The CCB is typically chaired by the product manager and has the major stakeholders of the change request such as the project managers of all ongoing projects and the line managers supplying the resources as members. The CCB is moderated and administered by a configuration manager.

While I can’t see any real alternatives to the above process and I have implemented it in several organizations, there are several challenges associated with doing so. I will return to these in future posts. A nice thing with the above process is that it plays very well with Scrum and other agile methods. This too may be the topic of future posts.


[1] Michael Porter. Competitive Strategy.

Published by Arto Jarvinen on 06 Jan 2012

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 with papers I have collected throughout the years. I happened to find it online [1] so that I can share it with you too.

The paper discusses what organizational form to choose for a project based on the nature of the project. The paper in the beginning emphasizes that it only deals with the “project organization” dimension of the project, not the “project management” dimension. The two dimensions are strongly correlated though as is demonstrated in Fig. 6 in the paper. In the functional end of the spectrum there is no project coordinator which obviously implies less focus on project management; the stronger the project organization, the stronger the project management function.

So when do we need a strong project organization and hence strong project management? This is discussed in Fig. 5 in the paper. Basically it says that when there is high uncertainty, new technology, high complexity, long duration, large size, one or a few customers, and high time criticality – in short when there is high risk – we need a clear project organization and strong project management. (See also this earlier post.)

When the opposite is true (low risk), then we can do with less project management and spend more of our resources on the technical tasks of the project. With low risk we can also think more “product” than “project” as discussed in my previous post.

When a product has been firmly established on the market (think Microsoft Word), most major customer risks, technology risks etc have been eliminated. The need for strong project management with all the risk management bells and whistles thus decreases. In this scenario the product is typically market driven to a high degree with a steady stream of new feature requests or correction requests (“bug reports”). Each such feature request or correction request needs to be analyzed on its own merits with respect to cost and benefit in a process that can manage the continous flow of requests. Once thus analyzed and decided, and given that the new feature doesn’t imply any major risk, there is less need for full-blown gate reviews and the rest of the project management apparatus when implementing the feature. We instead have a situation where Agile project management and development methods suit well. The list of approved feature requests maps nicely to the product backlog of Scrum and the informal risk management methods of Scrum [3] are sufficient.

Cold Fusion
Ready to go under the hood? (Source: Wikipedia)

It never makes sense to throw in one or a few high-risk features in an otherwise low-risk project. With other words, research and development should not be mixed in one and the same project. One high-risk feature amid 15 low-risk features may still determine the risk of the whole project and thus the required degree of project management. My favorite illustration of such a high-risk feature would be cold fusion as the suggested power source for an upgrade of an excavator or a similar machine. Regardless of how trivial the other added features are, the project will have a high risk of failure. Instead the cold fusion drive should be developed as a separate research project to remove most of the risk. (Good luck!)

For the continuos decision making and implementation of new features in an Agile process to work, the new features must thus carry a low risk. [2] and [3] describe how the residual risk can be managed in Scrum. (Note that [3] does not compare Scrum to a Stage-Gate model but some kind of very traditional everything-up-front waterfall model which may not be very realistic.)

I will write about the process of deciding and continously implementing new (low risk) features in a future post. Scrum covers part of the process but I’d like to add a thing or two.


[1] Organizational Alternatives for Project Managers, Robert Youker.

[2] Managing Risk with Scrum, Vikas Hazrati.

[3] Managing Risk in Scrum, Valerie Morris.

Published by Arto Jarvinen on 25 Jun 2011

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 bit but I believe this project focus comes from the culture that also was the origin of process improvement: large, multi-year, military projects. Each project was almost like an enterprise in its own right. These projects by their nature also carried a high risk which is best managed in a project context. (See this earlier post.)

Many software projects today are only one in a series of projects throughout the life time of a product. Most commercial software go through cycles of improvement, sometimes in the form of “patches”, sometimes in the form of larger upgrades which come with new functionality.

With a large number of projects, presumably working on the same specs and code, enhancing and refactoring it, it often makes more sense to focus on the product instead of the project. Regarding the bullets above this would for instance mean:

  • It makes sense to early on in the product’s life cycle develop a standard development process for the product instead of inventing a process in each project. This would mean going for CMMI maturity level 3 early on.
  • The configuration management plan should be written for the product, not the project. It makes little sense to change the way the data is managed from project to project. This would in fact impede (re-)using the previous versions of the specs and the code as a starting point for the next project. And it would be really difficult to see how one could have different configuration management plans for parallel projects working on the same set of specs and code.
  • The repositories holding the specs and the code (e.g. the configuration management system) should of the reasons mentioned above be organized for the product so that e.g. branches would be possible to make for parallel projects.

Published by Arto Jarvinen on 30 Dec 2010

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 method to better prepare for the new organization. The method can be used either to design the new organization and the new processes or to “test drive” (verify) the new organization and processes after they’ve been designed but before they are launched. The method is inspired by the ideas of Ivar Jacobsson described in [1], in particular the concepts business use case [2] and sequence diagram [3] as applied to organizations rather than IT systems.

The verification method suggested is based on two assumptions:

  • The organization exists to provide services or products to external parties. Providing such a product or service requires interactions between the organization and the external parties. These interactions can be describe as business use cases, i.e. short “stories”. The business use cases in turn are realized by activities inside the organization (together forming a process) performed by a number of roles. (See [2] and the example below for further clarification.)
  • The most important aspect of getting something done is that somebody is responsible for doing it and that the “baton is passed” between the different roles participating in the process so that nothing falls between the cracks. The exact method each role uses to get the job done is of course also important but not as important as that there is somebody there to do the work in the first place. People usually find ways when they know it’s their responsibility even if there isn’t any prescribed method and methods can be designed later if needed.

The method is centered around the creation of one or several sequence diagram(s) representing the process(es) and the roles realizing the associated business use case. (See below for an example.)

The sequence diagram should be created interactively in a workshop by a workshop leader and with all line managers likely to provide resources to the process present. Once all resource providers agree upon the sequence diagram and thus the process it represents, the process and the organization is considered verified.

The following steps can be used as a guideline:

  1. Select one or a few business use case(s) to analyze. In the example below the business use case is “get support”.
  2. Identify initiating event and role (“business actor” in [2]).
  3. Identify involved roles.
  4. Draw the sequence diagram together. Add and remove roles and tasks until a reasonable workflow is found.
  5. Identify risks for delays, bottlenecks or other potential problems with the drafted sequence diagram, e.g. by asking the following questions:
    • Does the task add value?
    • Is the role receiving an task request likely to have the right skills to perform the task?
    • Are the right incentives in place to perform the task?
    • Are there enough man-hours available to perform the task?
    • Is the task a natural part of a role’s responsibilities or a “hack”?
    • Is the required information for performing the task readily available?
  6. (Optional step) Suggest allocation of roles to departments.

Depending on the degree of consensus going into the workshop and the complexity of the processes, a two hour workshop might only suffice to cover one single business use case realization (sequence diagram).

The sequence diagram below represents a (simplified) realization of the business use case “get support” and is thus a (simplified) example output from a verification workshop.

Customer support process

A business use case realization.

By creating the sequence diagram we have shown that we have a reasonable organization and process in place to solve this task. Among other things we have shown that:

  • There is somebody to receive the support requests and that the customer will get a much wanted acknowledgement of the reception of the support request.
  • The first line support will not get stuck in hard-to-solve problems but can give fast answers when such answers are available.
  • There is a path for solving product issues (“bugs”) with a developer on call (and that such a developer on call must be allocated).
    • Other typical business use cases that could benefit from this type of reasoning could be tender creation, request for a new product feature, scheduling of a new project, and creation of the annual business plan and budget. Some interesting questions will undoubtedly surface when working through these business use cases.


      [1] Ivar Jacobsson. The Object Advantage.

      [2] Business Use-Case Model Guideline

      [3] UML basics: The sequence diagram

Published by Arto Jarvinen on 24 Oct 2010

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 and C where A might be “define the system requirements”. Standing on the level where A, B, and C are described, A could indeed be said to describe a “what” (the “what” being to define the requirements). It doesn’t say anything about “how” to define the requirements.

Now, let’s say that A, B and C are all parts of a higher level process description called “system development” which is one of the business processes of a development organization (along such processes as “system maintenance” and “customer support”). Standing on the business process level, “system development” would be a “what” but A, B, and C would rather be the “how” of system development as they would answer the question: how is a system developed (it is developed by (A) defining the requirements, (B)…).

Conclusion: depending on your perspective, a “what” can be a “how” and vice versa. Looking downward in a hierarchy of process descriptions you see the “hows”. Looking around you at one of these “how” levels you instead see a lot of “whats”. So when you use the (imo false) what – how dichotomy, please at least state whither your head is turned.

Published by Arto Jarvinen on 06 Sep 2010

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 find them utterly boring and way too detailed.

I don’t subscribe to the failed concept view. There is the need for personalized knowledge and for codified knowledge [1]. Although organizations according to [1] should focus on one or the other, there are very few organizations that would not benefit from some codified knowledge in the form of an operations manual. Engineering organizations with many quite complex but to some extent repetitive methods would definitely benefit.

The boring part could well be true but then again, you could say that of many other phenomena in an organization. I don’t get too excited about expense reports or the budget process but I still realize I need to put on a happy face. And there is as far as I know no clause in ISO9001 or any other standard stating that the prose of the operations manual shall be dry and dull.

Still, all too many operations manuals are collecting dust (physical or digital). There are reasons for this beyond the lack of faith in the concept and the disdain for dull details. Here are a few common ones:

Custom figure
Consider using a formal method such as the one implemented in the Eclipse Process Framework for defining the operations manual.
  • The people who create the operations manual don’t know the operations well enough.
  • It is not clear what the operations manual shall be used for.
  • Nobody is accountable for the operations manual.

I’ll say a few more words about these three reasons below.

The people who create the operations manual don’t know the operations well enough

Writing a good operations manual requires a rare set of skills. You need to be good with words, you need to know quality management which is not a small area of study, and you need to have deep knowledge of the operations and the business goals of the particular organization. Some humor to spice up the prose and artistic talent for making good-looking illustrations would also come handy.

In large organizations the operations manuals are often written by people not directly involved in the day-to-day operations of the company and therefore not necessarily familiar with the details of the operations. These people can write good operations manuals provided that they do a lot of “floor-walking” and are willing to learn the nuts and bolts of the operations. Manuals on a too abstract or too generic level will invariably collect piles of the aforementioned dust.

It is not clear what the operations manual shall be used for

I often hear that the operations manual should exist so that “people can consult it to find out how to carry out their tasks”. This undoubtedly sounds right but requires some clarification. Since every project and every department is unique in some ways, one process (perhaps the only one in the operations manual) will not fit all.

My experience is that a layer of adaptation is needed between the operations manual and a project or between the operations manual and a particular organizational unit. A project may for good reasons want to skip a stage in the standard project management process. A department may need a role that is unique to the department or maybe even temporary. For projects a Project Specification usually fills the gap. The Project Specification points out the roles, processes, tools etc used in the project. It may refer to the operations manual or it may define some project-unique stuff. For each organizational unit a similar Department Specification can be created.

If we allow that additional adaptation layer, we can use the operations manual as a rather formal “blue-print” for the organization; a “reference manual” instead of a “user guide”. It may (and should) still contain all the useful checklists, templates, method descriptions and so on but to find the exact set of such checklists, templates etc for a particular project or department, the Project Specification or the Department Description should be the first source of information – the “user guide”. (Or you could just ask your project manager or line manager.)

Nobody is accountable for the operations manual

Very few useful things get done in an organization without accountability. The accountability should lie with somebody who has the necessary skills and resources (sorry for sometimes stating the obvious). Spread among the line managers, the accountability for the operations manual often gets too thinly spread. Line managers are usually occupied by day-to-day prioritizations and problem solving and don’t have the bandwidth to engage in the details of process design, role definitions and the like (just like they usually don’t get deeply involved in detailed product design).

One solution is to create a specific management level position that focuses solely on operational excellence. This role would be responsible for keeping the engineering organization effective and efficient which is naturally tied to the operations manual as it defines how to achieve that effectiveness and efficiency. Of course any existing “quality department” and its manager should be the first choice for this role as long as it is made sure that the department is focusing on operational excellence and has the will, the skills and the resources to work very closely with the people in the trenches.


[1] What’s Your Strategy for Managing Knowledge? Morten T. Hansen, Nitin Nohria, and Thomas Tierney. Harvard Business Review, March – April, 1999.

Next »