Notes to reviewers
This document is an unedited collection of notes. It concerns the Total Quality Management of a software product company.
It is a thinking vehicle for collecting information and ideas. Over time it will be massaged into a coherent framework. It is not necessarily intended to be a book but it could turn out to be resource material for a book or a course.
Much of this material is my own, based on my own experiences; much has been taken or adapted from other sources; much is what I have learnt from other people within Lotus.
If you have it, the second half of this document is nothing more than resource material - a mishmash of notes that will be built upon over time or purged.
All text enclosed in [...] is either comments on the document itself or extremely tentative material.
0 Introduction
Most existing books on Quality concern hardware product manufacturing companies. They talk in terms of defects per thousand units; scrap; re-work; and costs of maintenance. They use examples, from the car industry and electrical utilities. And they discuss problems of worker motivation, more appropriate to smokestack industries.
This has created a false impression that Quality concepts and techniques are not appropriate to software product companies or other companies whose operations are design intensive. People also miss-apply Quality concepts to the software development environment. The concept of zero defects, for example, is often equated to the elimination of defects in a software product. This is a serious misunderstanding. Total Quality Management is so much more than this. Quality concepts can be applied to a software development environment.
Given the inherent complexity of developing a software product, Total Quality Management has the potential for far greater benefit than in the traditional hardware product manufacturing industries.
The basic concepts of Total Quality Management can be applied to any company or organization. In a typical software product company, like Lotus, there are a number of functional groups: marketing (both sales and product marketing), development, quality assurance, documentation, manufacturing, distribution, sales, customer support, finance, human resources, public relations and more. Total Quality Management techniques can be applied to each and every one of these. The principles are common. The precise implementation, however, does need to be adapted to meet the requirements of the individual groups.
This document primarily concerns itself with the design and development of a software product and thus the main functional groups it concerns itself with are product marketing, development, quality assurance, and documentation. However, the creation of a product involves every group within an organization and the interaction with these groups is also addressed.
0 Total Quality Management
Total Quality Management (TQM) is a philosophy of pursuing continuous improvement within an organization to increase the effectiveness and flexibility of that organization as a whole.The material in this section has been adapted from the book Total Quality Management by John Oakland.
Continuous improvement is achieved through the integrated efforts of all members of an organization. It requires the participation of every single person at all levels within an organization.
Each individual needs to clearly understand that for their organization to be effective, each part of it must work smoothly together. They need to recognize that every person and every activity affects and in turn is affected by others.
Every person in every department needs to work together to eliminate hassle, improve productivity and better meet the needs of customers.
The benefits of making sure things are done right the first time are enormous, in terms of greater efficiencies, lower costs, improved quality, better reputation and greater market share.
Total Quality Management can be applied throughout an organization. It applies equally to marketing, development, quality asurance, documentation, manufacturing, distribution, sales, customer support, finance, human resources, and public relations.
When adopted, organizational objectives automatically follow: customer loyalty, revenue, profits, market share and stock holder value.
[Emphasis that TQM is about people taking responsibility and making a commitment to continuous improvement.]
1 The Principles of QualityThe material in this section has been adapted from the book Quality is Free by Philip Crosby.
1.0 Definition
Quality is defined as conformance to requirements.
Products, services, or processes that conform to their requirements are quality products, services, or processes.
1.0.0 Products and services
Everyone provides products and services to their customers.
Products and services are not only the end deliverables provided to a company's customers. They also include the products and services provided by individuals and groups (suppliers) to other undividuals and groups (customers) within a company.
If an individual or group provides information in the form of a document, for example, to another individual or group then that document can be considered a product. When the individual or group responds to queries concerning that document, then this can be considered a service. When consultancy is provided or when the document is updated in response to a customer requirement then this can be considered a support service.
1.0.0 Processes
A process is a series of actions that produces a result.
Every job is a process, a series of actions that produces a result. These results are the products or services that satisfy the needs and desires of customers. To meet customers' expectations, their requirements, first need to be identified.
1.0.0 Conformance
Conformance means that the outputs you produce and deliver to your customer will meet all the requirements that you and the customer have agreed upon.
...
1.0.0 Requirements
Requirements are defined by the needs of the customers.
Requirements are defined by the needs of the customers for products and services.
In terms of products and services, Quality is as perceived by the customer.
The customer is the final arbiter of quality. The primary measure of a company's success is customer satisfaction with the company's products, services and people.
[Jo Donohue: An individual coding a program or writing a document may perform that task very inefficiently but still provide a quality product to their customer. They may spend a lot of time inspecting quality in rather than coding the document correctly in the first place. Their work process my be poor and inefficient. But if they produce a quality product at the end of the day who cares? The answer is simple: if the individual takes their job seriously and is committed to quality then they will work hard to improve their own work processes to eliminate their own personal rework and hassle. In this case, the individual's pride, self-esteem, conscience is their "customer". Remember there is usually more than one customer of a service or product if you look hard enough!]
1.0.0 Customers
Customers are those who receive the output of a process.
There are internal (immediate) and external (ultimate) customers. The external customer is usually the consumer of products and services marketed and sold by a company. Internal customers are usually within the company.
1.0 System for Achieving Quality
Quality is achieved by preventing nonconformances.
Quality cannot be achieved by correcting nonconformances in products, services, or processes after they have been made.
Quality is about doing it right the first time and not wasting time by going back to correct nonconformances.
1.0.0 Nonconformances and Defects
A nonconformance is a product or service defect or some other failure to meet customer requirements.
The word defect is often used as an alternative to nonconformance. One can talk of a defect in a product such as a bug in a software product or a defect in a piece of information such as an incorrect fact. In this case the words defect and nonconformance can be used interchangably. However, if a product fails to meet customer requirements through late delivery then the word nonconformance is a more appropriate term. Throughout this document the general term nonconformance has been adopted except where the word defect is more specific.
1.0 Performance Standard
The Quality performance standard is continuous improvement.
Every individual and group within a company must commit to the continuous improvement of Quality. The ultimate goal is to eliminate nonconformance in everything that is done or created and thus eliminate nonconformance in the products and services provided by a company.
If you don't strive for Zero Nonconformances (Defects); if you take the attitude that close enough is good enough then you will never improve.
It doesn't matter if you believe that zero nonconformances is impossible to achieve in any specific area of activity. It remains the goal. Individual commitment to continuous improvement is the bedrock of Total Quality Management.
1.0 Measurement
You must measure your outputs against customer requirements.
1.0 Cost of Quality
As Quality increases costs go down.
There are three elements to the cost of Quality.
1.0.0 Cost of Conformance
The cost of conformance is the cost of everything that is done to ensure that requirements are met with no nonconformances.
It includes prevention, inspection and appraisal.
What it costs to do things right!
...
1.0.0 Cost of Nonconformance
The cost of non-conformance is what it costs in dollars when you fail to deliver Quality to your customers.
The cost of non-conformance is determined by measuring the cost of correcting nonconformances or the damage caused by those nonconformances once they have been introduced into products, services, or processes.
What is costs to do things wrong!
...
1.0.0 Cost of Lost Opportunity
The cost of lost opportunity is the revenue and profit lost due to lost customers (current and potential) due to lack of quality.
It is indicated by decline in revenues, profits and market share.
...
1 Management's Role
...
1 The Individual's Role
Every individual must make a deep personal commitment to reducing nonconformance and improving quality within their sphere of influence. They must adopt the attitude that, with this commitment, they will embark on a journey of continuous improvement.
The commitment and attitude of individuals to TQM, is the key to its success. This fact can not be understated.
Individuals need to constantly strive to understand, meet and communicate the requirements of their work processes, if they are to improve their work. In addition, they need to use the experience that they gain to look for ways to improve.
If they wait for a sweeping change from above to improve the processes they operate, they might wait for a very long time. But if they actively look for better ways to operate their processes, they can help improve them.
It is inherent human nature for individuals to want to do and be their best. Quality defeating behaviours are learned behaviours that result from de-motivating forces that individuals experience. Therefore, any successful TQM process must systematically reduce the de-motivating forces and hassle that individuals experience in the workplace. Usually, doing this also eliminates many causes of nonconformance.
At the same time, individuals in an organization that is adopting the TQM process must be willing to put aside doubt and cynicism and Give Quality a Chance. The vast majority of people are eager to do this once they understand the pronciples of TQM. They understand that their commitment is of direct benefit to themselves, because it results in greater job satisfaction.
...
I know of no more encouraging fact
than the unquestionable ability of man
to elevate his life by conscious endeavor.
than the unquestionable ability of man
to elevate his life by conscious endeavor.
Henry David Thoreau
By far the most powerful force in an organization to bring about change and improvement in Quality lies with the individuals in that organization.Individuals in an organization need to make a personal commitment to continuously look for opportunities to improve ... not just processes and products but themselves ... people are the information machines that add value to information - their quality is key ...
The role of the individual is extremely important. In a software product company it is each and very individual that makes Quality happen. Each person modifying their attitudes and their ways of working to insist on "doing things right first time"; to not tolerate shoddy work; to continually influence people around them and in particular management to ensure that "things" are done right.
People often abdicate responsibility - they recognise a problem -they go to managament and suggest a fix, management say no we haven't got time - their peers don't support them - oh we tried to chance that last year but no one wanted to know - don't waste your time - but if everyone did not give up - if they took a longer term view and said this might take me a year more to bring about but I'm not going to give up - I'm going to slowly but relentlessy persue this - maybe in my spare time - maybe gaining the support of like people around me - over time attitudes and ways of doing things can be changed - just look at the changes in society's attitude to sex, religion, abortion, racialism over the last 30 years - it takes time but things can and do change.
individuals must take TQM concepts and apply them to their everyday work processes ...
they should not tolerate low quality service from suppliers ...
I will do my best within the constraints of my job! ...
If only I could change things ...
why if everyone thinks they are doing a good job is the place in such a mess? ... its not me its management or its marketing or its sales or ... Mark Levine's infrastructure of finger pointing ...
1 The Benefits of Total Quality Management
[This is an important section. It still needs a great deal of work.]
[Need an opening quote.]
Total Quality Management improves the effectiveness and flexibility of a business as a whole.
It eliminates hassle, improves productivity and helps a company better meet the needs of it's customers.
The benefits of doing things right the first time are enormous, in terms of greater efficiencies, lower costs, improved quality, better reputation and greater market share.
When applied, company objectives follow: customer loyalty, revenue, profits, market share and stock holder value.
These are the generic benefits of Total Quality Management. But what is the real advantage for a software product manufacturing company?
With the increasing power and sophistication of computer hardware, ever more complex software products are capable of being built. With the advent of multimedia, video, sound, high speed networks ... [Expand] we are entering an age where computer software products will increasingly fall behind the capabilities of the hardware. Software product companies that can rise to the challenge and organize themselves to develop this new generation of software products will be numbered among the major corporations of the twenty-first century.
The more complex a product, however, the larger the team traditionally required to develop it and bring it to market in a reasonable time. In turn, the larger the team, the greater the problems with internal communications and the greater the difficulty in managing the project to successful completion. In other words, if we think its tough today, its only going to get one hell of a lot tougher.
The adoption of TQM as a philosophy will enable a company to develop large, complex, sophisticated software products of high quality in a competitive development cycle with a small team and the minimum of hassle.
It won't be easy, a lot of work needs to be done to adapt the principles of TQM to a software development environment. For those who succeed, however, the rewards are enormous.
If you don't believe this then take the time to study how the Japanese have come to dominate the consumer hardware product industry through the adoption of TQM techniques advocated by Edwards Deming.There are many good books on this subject - see the bibliography. If you can stand being reduced close to tears at the short sightedness of the American car industry - read The Machine that Changed the World. Chapter 6, p.138, Coordinating the Supply Chain.
They may be 5 years or more behind the the U.S. and Europe in software development but over the next 10 - 20 years they will catch up as they learn to adapt their TQM techniques to the software products industry. We have an opportunity to give them a run for their money.
1 Differences between the Software and Hardware Paradigms
A paradigm is a constellation of concepts, values, perceptions and practices shared by an organization which forms a particular vision of reality that is the basis of the way that organization organizes itself.See p.88 Managing on the Edge by Richard Pascale.
One of the major hurdles faced, when thinking about software manufacturing companies, is that we have been educated and conditioned to think in the terms of hardware manufacturing companies. There are many differences between the two paradigms. Some of these are discussed below:
Software product companies are information companies. Their products and services provide their customers with information; not with material things.
The expendable raw resource of a software product company is time; not raw materials.
In a software product company, it is people and ideas that matter, not places and things.See p.356, Microcosm by George Gilder.
The manufacturing cost of a software product is low. The manufacturing cost of a software product is so low relative to the cost of typical hardware product that reducing manufacturing costs over time is far less important than that of a mass produced hardware product.
Software products do not age like hardware products. Software products do not wear out with repeated use. They are not affected by environmental conditions such as moisture, heat, cold, or lack of maintenance. In this respect designing a software product, like Lotus 1-2-3, is far easier then designing a hardware product, such as a car.
Compatibility with previous models (revisions) is more important to a software product than a hardware one. Software products like Lotus 1-2-3 are programmable tools. Users build applications with these products. With a new release of a product it is absolutely essential that a large degree of compatibility is maintained so that users do not need to modify and re-test their applications. This puts a great onus on the original design of a software product and severely constrains its evolution. Most hardware products do not have the same constraint.
- Note also the individual users investment in learning a product and an organization's investment in training. This also restricts the evolution of the user interface.
Software cultures are very different from hardware cultures. Education and motivation of the people different - "hacker" culture. People's attitudes are different. The cultures are different. No 9 - 5 ethic. Salary is not a major motivation factor. Worth exploring how this came about. It was never planned. A lot to do with the youth of the computer industry. The culture is not necessarily a good one - explore that.]
In a software product company, it is the people that are important. In a hardware manufacturing environment, we maintain machines, we perform preventative maintenance; replace them when they wear out or are superceded by superior models. In an information environment, we maintain people -train them, keep them happy etc. [Expand]
- In traditional smokestack industries you could force people to work against their will and they would produce acceptable if not great results. (Motivate by fear.) In an information world, we all know this just doesn't work. Motivation must come from within. Even a good salary and good working conditions are not enough.Toffler has more to say about this. I need to dig out the reference.
[Expand]
Machines have been replaced by people; raw materials have been replaced by information. The raw material is vast quantities of binary zeros that we craft by switching on and off in some complex fashion to create a product. Binary zeros are a cheap renewable resource. The real resource is people and their time. [Expand]
- Comparing Lotus 1-2-3 to a television is an interesting but maybe not a good comparison. Lotus 1-2-3 is a tool, a personal information tool. A better comparison would be with a personal hardware tool such as an electric drill. But here, the difference in complexity is even more apparent except maybe if one compared Lotus 1-2-3 with a numerically controlled milling machine but then such a machine has a large software component.
- This is not entirely true. Software product companies do use some prefabricated bit sets such as fonts; clip art; spell checkers; thesauruses; or electronic tutorials; and they do subcontract some components such as printer drivers. In addition operating systems increasingly provide more and more functionality that previously had to be provided by the applications. Unfortunately, applications are more than compensating for this by providing even more new functionality.
It is software that is important not the hardware that it runs on.Reference Microcosm by George Gilder.
We shouldn't worry if the U.S. is manufacturing less and less micro-chips, VCRs and personal computers. These are commodities. The real growth is in software: PC software products, information products, video films, information services. These are all information products. These are products of the mind. They have low capital start-up and they are people intensive. They are the growth wave of the future.
- In a software product company, the product is information. Information in the form of a whole load of binary digits on a few cheap discs. The media is worthless. The bits (information) worth millions. Even documentation is delivered initially in electronic form. Even more bits. How many million bits make a software product such as Lotus 1-2-3 release 3.0. Even more interestingly, how many million bit transitions were there; bits turned on and off and back on again to make the product? Also, think of all the information scaffolding: marketing requirements documents, functional specifications, design specifications, status reports, interpersonal e-mails. For good measure, digitize all the voice and visual communication and add in those bits. One awful lot of information gets pushed around one way or another to create a software product. And products are becoming more and more complex.
All a software product company deals with is information. We create it; we collect it; we shape it; we add value to it; we transform it; we do all sorts of wonderful things to it in order to make a product.
- New ideas: the spreadsheet, the icon, windows, fonts, hyper-text, user extension architectures, data access architectures. In the software world it is ideas that constitute technology.
Hardware technology development such as the development of new integrated circuit technology requires a massive investment and maybe years of expensive R&D by an experienced team with maybe little or nothing to show for it at the end. Only large companies can afford it. Software technology is a different animal. Its about ideas - one person in a shower (and a PC in their study) can develop and research software technology. Start-up costs are low. The real capital is time.
It is interesting to note that companies like Intel or Toyota have large research groups dedicated to the development of new hardware technology. Most software manufacturing companiess on the other hand have only small research groups dedicated to the development of software technology. This seems strange given what will be possible in the way of software technology in say 5 years time, given the predicted if not guaranteed hardware advances. [Is this true?]
Inspection is more efficient in a software product company. This is because once a defect is fixed it is fixed for good. Given current development processes and tools, inspection will be required for some time. Though the goal is to decrease dependence on it over time.
In a software product company, effort goes into design not manufacture. Manufacture is the easy part: print the manuals; duplicate the disks and assemble. Compared with hardware products, manufacturing is relatively defect free.
The manufacture of a software product is almost defect free, Once a software product has been designed it can be manufactured with almost zero variation, time and time again. All product units are the same; there is zero variation. If one unit has a defect then so do all the others. This is quite unlike hardware products.
In a hardware company, information is usually made available on a "need to know" basis while in a software company on a "need not to know". ...
- ... need to justify need for information versus need to justify why you shouldn't make it public ...
Given the fundamental differences between the two paradigms it is not too surprising that many misconceptions and myths have grown up about Quality and Total Quality Management. These myths are so pervasive that its worth discussing them as until they are dismissed they form a very real barrier to accepting and learning more about TQM.
[One of the biggest problems talking to people one on one especially a more senior manager is that they think they know what Quality or TQM is all about and do not listen - they spout the myths and all the reasons that why in their experience it won't work ...]
1.0 Quality is NOT free
I sometimes wish Philip Crosby had never said Quality is Free! Its a catchy title for a book and is easily remembered. Its meaning, however, is not well understood.
What Crosby meant was that if you invest resource (money, people, time ...) in a product then the interest you earn (in higher quality, higher sales, better market share ... ) more than pays for the original investment. In this sense Quality is free.
If you consider the investment an expense though and don't include the payback in your calculations then Quality is not free.
Viewed in the short term the cost of Quality is an expense. Viewed in the long term the cost of Quality is an investment with a handsome return.
I believe that the problem for most product managers is that Quality is really not free. The reason is simple. They are measured on the wrong objectives over the wrong time frame. They are measured on the time to complete the product, the head count, the cost in expenses and to a lesser extent the quality of the product itself (often bug count related). To my mind, managers should be measured on the return not the expense. Return should include not just immediate revenues but the long term returns of making the products extensible, portable, and maintainable.
1.0 Quality costs too much
[Customer support costs are very high. Wrong answer: reduce customer support! Right answer: figure out why they are so high ie poor quality products and fix the products!!! Its expensive to do that. Its more expensive not too!]
1.0 Process and Quality stifle creativity
[Rough notes ...]
Sevaral arguments along these lines are frequently heard. The first usually argues that most great software products were created by a small team (often only one or two individuals) working to a vision with extremely little process and not too much attention to Quality. Larger teams with more process and placing a greater emphasis on Quality rarely do as well. Thus process and Quality stifles creativity.
... need to distinguish between a new innovative product and the development of a new release of an existing product ... the process is different ...
... also note the difference between a program and a product -see Mythical Man Month ...
Another argument that people cite is that the writing of a functional specification that say fully defines the user interface of a product stifles creativity. They argue that you cannot specify a user interface on paper. They use this as an argument against having a process. This is just plain ridiculous. Just because something is done in a bad way in the name of the process does not discredit the process!
A user interface, should never be designed and cast in concrete on paper. A car manufacturer would never do this with the dash panel of a car. A user interface must be prototyped and fine tuned by observing real users use that interface. ... a specialist task - a great deal of hand crafting ...
So what really stifles creativity? Ask anyone what stifles their creativity. I suspect they will say the lack of time to sit back and plan and think about what they are doing. If hassle were eliminated they would have more time to be creative. TQM frees people of hassle and provides them the time to be more creative.
The word creativity is used in more than one sense:
1) As applied to new products. Does process stifle creativity in creating them?
2) As applied to new innovative features of an existing product or neat ways of implementing such features.
3) As applied to meeting deadlines. Creativity in dropping functionality, cutting corners, utilizing outside resources ...
To my mind, all three of these "creative areas" suffer if people are put under undue time pressure. People have no time to plan and think - simply to do! More haste less speed.
1.0.0 More notes on process verses innovation:
Manzi wants to push responsibility down the organization. This ties in with TQM.
Senior Management do not really care about the efficiency of the development process eg ITGs character tables - they want sizzle
Carty's comments on DEC Engineering: all the right processes, very predictable, consistency, relaibility but no innovation.
Why does process stifle innovation? Is it possible to design a process that doesn't. Are they really mutually exclusive?
innovation ok early in a project life cycle but late on - just ship it
What are our objectives in developing and improving a process
Hal, Manuscript, Jazz, Metro, Express, Marketplace, Signal, T-A-C, Symphony?
Why are MS and Borland perceived to be more successful than we are at shipping innovative products in a short development cycle
WYSIWG not in Godiva, Outlining not in Rockport
1. Missing Marketing Requirements
2. Too late to market
3. efficiency is not so important but helps (1) and (2)
list goals and prioritize them
if developers lose autonomy then they will be demotivated
high level cross product group reviews, critique, gather ideas ...
we are always in reactive mode - process should get us out of it ...
efficiency will hellp us catch up and get ahead
design for the long view - file structures etc - design to be extendable - no code rewrite - tremendous efficiencies - major realeases within 6 months
technology outpaces the mind-set - Patricia, Godiva and source control ... resistance to change, no time to investigate, risk ...
1.0 TQM is about eliminating software bugs
Its amazing how many people only think about product quality in terms of the number of defects in that product. If you talk to them - they bring the conversation back to this area time and time again. The reason is that this is as an area that is critical to the shipment of the product. It is also easily measurable and there is usually an existing function set up to rid products of bugs ...
1.0 Zero defects is impossible for software products
Lets face it with today's software technology and development methods its impossible to ship a complex software product without defects. Some people pick up and thus and use it as a weapon to discredit the concepts of Quality as applied to a software development environment.
If they do, then they have misunderstood. Its the goal we are talking about not today's practicality of its realization. We should continually strive towards the goal of zero defects and not some acceptable level - we are talking about continuous improvement - its a subtle difference that many people miss.
1.0 In a software company it is impossible to get it right first time
In a software product company it is impossible to do it right first time because of budget and schedule constraints. A lack of a full understanding of customer requirements; rapid and uncertain technological change and changes in the market place only compound the problem.
Is this really true? What's different between a software product and say a car or a VCR? Don't the same difficulties apply? If it is true then what can we do to mitigate the effects of knowing that we "won't get it right first time"?
For a software product, if you do not get it right the first time then you are often in serious trouble. This is because it is often not possible to put things right the second time as forward compatibility needs to be maintained.
This is a serious problem and only underscores the need to get it right the first time. If we recognize from day one that forward compatibility is an essential requirement in itself then it means we should design a product to minimize the dependencies that a subsequent release may have on that version.
For example, we could tokenize macros so that command name changes did not affect forward compatibility; we could ensure that all data files had "revision" records to intelligently accommodate file format changes; and we could carefully review the design of all subsystems asking the question "if I need to change or expand this functionality in future revisions then what am I going to wish I had done first time around".
1.0 Its a great concept but we tried it at XYZ and it didn't work
So what! If you think its such a great concept then don't give up so easily. Learn from your own mistakes and those of other people and try again. The pay back is high - its worth the risk.
The other problem is that major battles consume time that could be better spent fighting smaller battles that can be won and that can be devastating in their PR effect - guerilla warfare again ....
But don't get me wrong - I'm not saying don't fight - I'm saying be smart about it!!!
So one product is not as good as it could be - cos you chose not to fight. But nows the time to point out the problems as they occur, document what happened - talk to and influence people over time - so that in the next release, the next product you work on - you are prepared - you can fight a battle that is winnable.
In fact I would go so far as to say as never fight a battle unless you are pretty confident that you can win it. Even if it means escalating - and i don't mean to avoid risk taking ...
[how to handle people who really do stop you doing your job and even may be actively trying to cause you harm for whatever reason - again don't fight them ...]
2.0.0 Escalation
So you can't convince someone to do something to better meet your requirements. Well, if you have a good case, that's easy, escalate the issue to their boss - they will listen. Or is it so easy?
The art here - is to do this without destroying your relationship with the manager and the team. Even worse at GM level - you can destroy your relationship with a whole group. I'm not saying don't do it - but play very carefully - get someone else maybe within the team to escalate for you - rather than directly talking to the boss - use the grapevine to get a word to their ear - so they ask the appropriate question for you. If you can only win at the expense fo the relationship - then may be you should drop it.
Many people would escalate and be damned. They would justify their actions by saying - "This is too important an issue to worry what people think of me - its my job to point these things out." There may also be a strong element of "I can get ahead by showing them up". This is a very individualistic combative approach. These people are rarely team players. I'm not here to concern myself with people's feelings. They feel very superior about it - a very go go macho attitude. Some survive and do well in the short term but sooner or later - they raise stink about something they have got wrong - and everyone turns and pays back out debts - the get knifed.
2.0.0 Personal battles
If you need something from someone and you don't have the authority to demand it - and they quite clearly will not give what you want - do not push them to the extent that it damages your relationship with them. This is a common mistake. Once a relationship is damaged, it can take years to repair and may never be repaired. The other person starts to bad-mouth you and you're in real trouble.
Maintaining the relationship and your ability to influence a person over the long haul is far more important than winning a contest of wills. Even if you win, at the expense of the relationship, - it may be your last meaningful exchange with that person.
[E and H -tell the story.]
2.0.0 More on influence
You ask someone to do something for your group, your part of the company. I'm a support guy and I want a product to more easily supportable, for example. They can decide to do what you ask or they can decide not to do it. In your meeting with them, you can use all your persuasive powers to get your own way. You can be forceful, demanding, you can threaten (The CEO wants this. If you don't do this small thing - I'll escalate the issue to your boss. You are not thinking of the company, you are not thinking longer term.
This approach can and does work. However, it is a short term solution - its a put out the fire solution. You can threaten and intimidate anyone to do anything. But they will resent you with a passion. The first chance they get to wiggle out of the commitment; to find fault or contradictions in what you have asked they will. In our environment - you need to be there intimidating all the time. Next time around when you are not there and the same situation arises - will they do what you need - like heck - in fact they are more likely to do the opposite -this is often not deliberate - its subconscious - its just human nature - if you talk to someone about their reqs and they give you a hard time - if you come away feeling manipulated - if you feel bad about yourself or them - then even when you know you should talk to them again it is easy to procrastinate and put off talking to them even when you know you should.
What's missing here - is a longer term view - the need to establish a warm friendly personal relationship - if someone is to do what you ask - they need to like you, they need to understand the bigger picture over a period of months if not years - they need softening up - they need to be pre-disposed to your requirements - they need to personally believe in your mission ...
2.0.0 Quality relationships means quality products
How are quality relationships related to quality products - doing it right the first time? They seem to be mutually exclusive. If people do not have quality relationships with each other and if there is not a free flow of information and ideas then how the hell is a company going to achieve a quality anything?
A lot of what I say above seems to imply accepting an inferior quality product in order to preserve quality relationships. How do we square this away? If as individuals, we can force a perfect product but in doing so destroy our relationships, then we'll get it right this time but forfeit getting it right ever again. This is another short term/long term balancing act. If we put quality relationships first, then quality products will follow. Just like if we put quality products first, revenues and profits will follow.
2.0.0 Influence
[How to change things slowly over time. How to get things done that everyone refuses to do today. This will turn in to a substantial section.]
Need to influence how people think. Not what they think.
2.0.0 Authority
[Even when you have authority and control be careful how you use them - this is a section in itself. Don't dictate unless you must - remember that quadrant chart from old management course on delegation etc]
2.0.0 Policing
[Policing or enforcing groups to do things verses encouraging them to take responsibility ...]
2.0 The breakdown of the hierarchy
In information companies everyone is a specialist. No one person can understand the complete system anymore. There is a move away from organizational hierarchies towards networks of people.
Every one is interdependent. Everyone has a degree. Everyone is highly motivated. Everyone wants to create a perfect product. Everyone is an executive. [In the Drucker sense].
[I can talk to anyone without reprimand. A great break through. Managers are not so scared any more. Its more difficult to manage by fear. People have a lot more latitude in what they say and do.]
2.0 Collaboration
*** Collaboration is a key element to all of this. The breakdown of them and us, management and workers. Managers have no real power. We are all equals. We are relentlessly moving towards the day when whole companies will be run as collaborative efforts, senior managers will lose a lot of their traditional power and their salaries and perks will come down to more modest levels ... they are part of the old paradigm ... No one can stop this happening - it is inevitable.
collaboration - need meeting areas, Lotus bar/restaurant etc ...
collaboration - need a lab as described in Shared Minds ...
Lotus should be developing collaborative products a la MIT ...
what went wrong with Communism!!! some memes were good (collaboration), others were rotten to the core ... remember genes and memes survive because they do not because they are better then those that don't ... environment determines this but then they also affect the environment ... does a paradigm equate in some way to the meme pool.
2.0 Costs verses opportunity
Costs are not so important in software development (ie in design verses manufacturing). The saving of $100,000 is maybe less important than spending $100,000 in order to make $1,000,000. If you only have time to do the one which do you do? Remember time is the raw material
It is often more important to save time than money. To get a product to market quicker, for example. - intl enabling - more important to get products to market sooner rather than save costs in Dublin. Also problem of hiring and training people - the smaller the team the more efficient - less complexity etc -should be possible to model this mathematically in some way ...
2.0 Short term verses long term
Managers need to concern themselves with both the short term and long term.
2.0 Holding market share
The fact that a product holds market share is not necessarily a sign that users are satisfied with the product. If for compatibility reasons they stay with the product but are dissatisfied with the new revisions, the service etc but are trapped. Then we have some very frustrated customers who will jump ship at the first possible moment. [Expand.]
2.0 Quality of process definition
You can measure the quality of the "definition" of the process and you can measure the quality of how the process is operated in practice.
[Is this a useful distinction?]
2.0 Deliverables
[New notes - unedited]
See Aren's docs:
Business Plan, Marketing Plan, Functional Specification, Test Plan, etc
A corresponding process to create each of these docs.
There should be a template for each doc with advise as to how to complete the doc.
There should be a set of guidelines for the operation of each process.
There should be a checklists to measure both the quality of the docs and the quality of the operation of the process.
2.0 Notes from conversations with Terry Rogers and Don Casey
His people came to him and said they wanted to build quality in up front and not inspect it in - his response was fine - as long as it is cost neutral - but they weren't prepared to take the risk and disband the inspection bit - so its not happened - so his people aren't prepared to take the risk and nor is he - its going to cost more to find out if its possible to cost less or maybe it will cost more but the quality will go up (when quality goes up long term returns go up and long term costs come down) -Lotus is unforgiving if they screwed up they would be fired ...
so how about trying it on a non-time critical product .. no pain no gain ... the Japanese just do this as a matter of faith ....
Don Casey: stifle creativity, all great products work of v small team with no process ...no such thing as zero defects ...
cooperation v competition ...
everyone believes in it but everyone is afraid to try it (me) ...
2.0 Expense verses Investment
[Notes]
a) spend x and get product Y
b) spend 2x and get product Y (inefficient)
c) spend 2x and get product 20Y (good investment)
But how do you measure a product to be 20 times better than another? We have no measure of efficiency in our development process. Remember it needs to be measured over the long term. We could try listing the things we would like to measure -portability, maintainability.
Develop concept of invisible costs and invisible returns ...
Major issue: American corporate culture is so focused on the short term that they miss the obvious. Its genetic, its inbred, people are pre-conditioned, its cultural. It will take several generations to change. The Japanese have a long lead. All they have to do is learn how to apply their techniques to software products. (Its a little like the problem of the Russians and Eastern Europeans catching up economically ...)
2.0 Prototyping
[Notes]
The current development process does not include prototyping. (Well actually it does, but we end up shipping the prototype!)
Is this a major issue? If we accept the fact that requirements are so important then maybe we should spend a lot more time defining the "evaluation phase" of the software development process as at the end of this phase is produced the functional specification. Prototyping seems to fit into the evaluation phase and is vehicle for collecting and better understanding customer requirements.
2.0 Memes, Evolution, Natural Selection, Paradigms, Meme and Gene Pools
*** investigate how the concept of memes relates to paradigms and TQM (The Selfish Gene, Richard Dawkins, p.206). Evolution and natural selection applies to memes. Can we accelerate the evolution of memes by using this as a model?
1) scientific theories ... ideas, memes ...
2) organisms (genes)
3) organizations (ideas, memes)
does the paradigm equate to the meme pool
idea of diversity both genes and memes ...
Darwin - evolution .... paradigm shift - p.107.
hysterisis curve, magnetic domains, environmental challenge, hostile, change, mental force field, magnetic force field, ... this verges on a fundamental understanding of evolution/revolution ...
... cannot take Japanese techniques - paradigms and graft on to American way of doing things - its like uprooting an an animal adapted to its environment over hundreds of thousands of years being thrust into another environment - the anmimal will die ...
... genes and memes are self supporting - change one and you affect all the others in the organism or organization to some extent ...
Paradigms: manufacturing; organization; people/diversity; management; quality; education ...
concept of remenants of the old paradigm littering our minds -programmers are lazy they do not want to re-use code - they are not interested in quality ....
off with the old - on with the new ...
prejudice, pre-conceived ideas ... ghosts of the old paradigm ...
2.0 Diversity
reason for diversity focus in Lotus: 1) changing job pool and 2) the more diverse the workforce the more creative it is ...
Scott Tucker thinks that both of these are marshmallow thinking ... (1) the Lotus job pool is people with CS and MS degrees - not a very diverse pool at all and for (2) there is no proof ...
I don't agree with him on either but I have no proof ... (1) can be easily measured
"People just aren't what they used to be." p.75 The Adaptive Corporation by Alvin Toffler ...
(2) I'm just convinced of - but what proof???
2.0 Re-use of Code
... Patricia and her questionaire to developers ... just goes to show you should not jump to conclusions ... this seems to be soemthing that should be built into TQM - this is about determining the real root cause of a problem ... "cause and effect diagram" ...
2.0 More on Benefits
focus on customers, on individuals, on doing it right, on individual responsibility
2.0 Miscellaneous Quotes
If you are up to your ass in alligators when will you ever find the time to drain the swamp.
Why get it right the first time when you can ship a point release.
There's nothing that so concentrates a man's mind than the thought of being hanged in the morning.
"under the gun"
There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success than to take the lead in the introduction of a new order of things, because the innovator has for enemies all those who have done well under the old condition, and lukewarm defenders in those who may do well under the new.
- Niccolo Machiavelli. II Principe (1513)
some sort of accent on last o ...I will have thousands of bugs to fix, so I had better start writing that code now. Allen Olsen (Lotus Development)
2.0 Miscellaneous notes on people
Elaborate on personal commitment to Quality. ZDs, answering phone calls. Use of e-mail, Notes, Agenda etc. Give examples. Do it right first time. Give feedback (complain!). Example of payroll, crossing the road, dropping a new born infant ...
People don't co-operate with other groups because they want to minimise hassle eg share code. Minimise dependencies ... fundamental rule of software development.
troublemakers are often people with a high intelligence level but low frustration threashold - they get emotional and bitter when the "obvious" things don't get done.
Use quote from George Gilder on people ... p.113 ...
People are not commodities.
People need to own the process.
"no commitment without involvement ..."
2.0 Information
From a software development point of view, Quality can be used to describe all information or processes or procedures that produce or deliver information. Hence the term Total Quality Management. Quality in everything that we do.
The word quality can be used to describe:
(a) information (program, manual, document etc)
(b) processes that produce information (design review)
(c) services that provide information (beta test)
(d) the delivery of information (presentation)
(e) the collection of information (market research) same as c
[In the words of Xerox: the collection, analysis and dissemination of information ...]
Ultimately it is the quality of a product or service that a company provides that is important. It is this that is seen by the customers.
2.0 Documenting Processes
[unedited brain dump]
[In a software product company, it is important to understand how processes have evolved to their current form and to document the way that they work. I'm not talking about the whole process but one can take a sub-process such as beta test or the writing of a functional specification or the translation of US documentation into a local language.
Having documented a process, the document can be distributed for comment and feedback, to review it, to call meetings to discuss it and refine how the process should work and update the documentation. This updated definition can then be communicated to all those who need to know how it all works. A Quality Improvement team could also be set up to investigate the process in depth and improve it.]
[It helps is there is some enveloping process in which the sub-process can exist and relate to but it isn't a pre-requisite. Lotus defined and refined a good beta test process long before it defined an encompassing software development process.]
[New section, Unedited.]
Processes, procedures, roles and responsibilities are examples of things that should be clearly documented. People will often ask "Why bother? No one will take the time to read this!". And to a certain extent they are right - but its no reason not to do it.
Let me explain. First, you should document things for yourself and your team. The actual act of documenting a process forces you to think hard about it; to structure it; to simplify it; to ensure that it is coherent. It enables you to see the holes and ask questions in order to fill them in. Its rather like programming - its not until you write the code that you really understand the problems and discover all the little quirks - all those error conditions etc.
[Carefully condensed and crafted by a professional writer.]
As for other people reading the document and understanding it that's a secondary issue. When the document is distributed, some people will read it and understand. Others will not. But when you talk to people about the process you can bring out the document and walk the person through it. When a new manager wants to know the procedure - the doc can be given him - new hires are always keen to learn the company procedures this way.
The point that I'm making, is that sure people will not read the document overnight and follow the process the following morning. It takes time and this is to be expected. This is ok.
There are other ways of communicating the document. Always put an executive summary at the front of the doc. Always keep it concise and as short as possible. Ie Make it easy to read. Also maybe give a presentation or presentations on the subject. You need the document to be able to do this. But give the document out at the end of the presentation.
Don't let the document die. Keep it updated. Publish an available documents list. ...
2.0 The Software Development Process
[The total (umbrella) process for developing software products. Aren's work. A skeletal structure on which to hang all the sub-processes.]
2.0 The Cost of Lost Customers
Idea of a lost customer worksheet to calc total lost revenue over 5, 10 years.
2.0 The Elusive Silver Bullet
People are looking for instant answers. Quick fixes. They are imaginery. They are looking too hard. Focusing too intently. They do not see the wood for the trees. They need to ease off, step back, and look at the whole.
2.0 Investing Time
... if I told someone they could save 10 days effort next year by investing a day's effort today they would say great but I haven't got the time - the reason is that they didn't invest that day's effort last year either ... people have got to learn to start to put some small part of their time away for te future (eg localization reports ...)
2.0 My E-mail on PONC
why are we measuring?
we don't measure to blame but to improve
we don't want to eliminate risk taking - just measure how good we at it and improve - risk taking is essential ... its ok to fail ... ok to risk 100k to make 100m or create a new market ...
the money and its saving is not the issue
we could save money by not taking riskas but then we would stagnate, need to improve the process of risk taking ...
2.0 Ideas and short notes
p284 Man on the Edge - evolution ...also p267 and p272
p25 Manthe s/w process - good bit on requirements ...
*** Quality Policy ...
Need a section on reusable code.
Below GM level - no one cares about costs - well almost.
we don't do a break-even analysis on products
TQM empowers people to do things for themselves
change of management attitudes
before commitment checkpoints if you raised issues - you were a troublemaker
doing the right things (Senior management) and doing the right things right (development)
Carty Castaldi and comments on problems of application integration - not technical but people.
QA:dev ratio: 1-2-3 3:1 - should be the other way around ...
most developers at Lotus have never met a customer ...
how do you solve communication problems without over documenting ... lots of small seminars ???
U.S. culture is a barrier - individualism ...
need to demo a product to management early - its a visible measure of progress ....
Does JIT make sense in software development?
How does TQM relate to Lotus's diversity and operating principles ...
need to incorporate quality goals and objectives into people's objectives ...
Management will always commit to do doing the right thing but providing resource is another matter.
Definition of long term planning "What will the share price be by the end of this quarter."
Management need to walk the process.
Ed McNierney - list of things that if I don't do - I'll get fired and list of things that if I don't do - I won't
The "sofware business model" (Eric J Wilson) - the need to ship product
TQM is not about delaying ship - its about improving it ...
Objectives: ship on time or improve the process - whch wins
According to Eric J Wilson our development costs are higher than our competitors.
People are in search of instant answers - eg CASE. Cannnot believe that attitudes and attention to detail makes the difference.
Software Conflict: p.183-p.185 Technology, p.195 Edcucation and good books, p.212 Problem Solving Process - a brilliant essay.
The Machine that Changed the World: p.148, Lean Supply in Practice. Also bits on development - see index.
Eliminating defects is not the point, if no one wants the product. TQM is more than this.
hockey v ballet; guerilla warfare. ballet is not a good analogy -there is the unexpected - warfare is the best!!!!
Adapt appropriate parts of Software Failure: Why Does it Happen? p.215 to p.222 of Software Conflict. Good piece on unstable requirements on p.218. Also good piece on scheduling "vaporware" p.216.
Do a section on TIME - its so important in the software world. Draw from Stan Davies book Future Perfect.
Draw from PeopleWare p.137 concept of a Quality-reduced product.
Reliability of software different to that of hardware.
Conflicting requirements. Example: platform standards or Lotus standards.
With hardware there is a need to get it right first time. With software it is too easy to change at the last minute and everyone knows it.
Roger Pressman has a book "Getting Software Engineering Right" or some such thing.
Lotus story of saving contractor expenses ... verses car suppliers.
Hiring freeze an effective but not good way of controlling costs.
Prototypes and products and process.
Linear software process does not work for prototypes - Ed Batutis and Chariot.
Use of contractors - loss of experience.
Beta testing - what is it?
Continuous = never-ending.
The product was defect free but still did not meet customer requirements. It did not conform to requirements.
A defect is a bug - something doesn't work as it should or something is incomplete. Meaning of the word varies depending on whether it is used to describe a product, a service, information or a process.
spreadsheet engine <-> internal combustion engine
Improve: smaller, more efficient, they do have some things in common - wear and tear is not one of them
Computers: speed, increased main memory, secondary memory, falling price, size, customer education, all these accelerate innovation ...
Problems of acquiring software like Allways and Impress. Not written to Lotus standards - lots of re-work - lots of longer term problems. We acquired these products to catch up - we shouldn't have fallen behind in the first place ... [Hot stuff ...]
Quality processes lead to quality products. Focus on the processes. (Analogy education and training.)
QFD - Quality Function Deployment - p160 of "The Man Who Discovered Quality."
Need to measure the quality of the product and the quality of the processes that produced the product. Measurements are mostly relative - the goal is continuous improvement. (Bear in mind all those uncontrolable environmental factors.) Should measure bugs, ship date delta, localized ship date, costs etc.
Hardware wears out, software does not. Hardware needs to be designed to stand up to its environment. The equivalent in software is it needs to be designed to evolve, can't afford to go back and re-write in one go. (There's a car analogy here ....)
Software has the burden of compatibility - forward, cross product, international etc.
Design decisions are routinely compromised because of lack of time due to pressure to ship.
company -> groups -> individuals
Software factories ...
Often small islands of competence in a company with a well developed process - Lotus - beta test group.
Little of this document directly addresses what it takes to create new innovative "sexy" products ...
Interdependence: Art of Japanese Management p.123
Need to say something about expectations
Myths: TQM means delaying FCS
Myths: it will cost more ...
p.79 Japanese Software Factories on measurement and p.80 on reusable code
Patricia Stimpson - idea of monetry awards for reusable code -NO! this is bribary! Also Eric J on % of revenue before and after ship date - sets a std to ship and sod quality ...
song writer writes for his/her self ..
top of p.102 Managing on the Edge - example of underlying mindset
*** TQM itself is a paradigm ...
*** the new paradigm turns accepted values and beliefs on their head ... list them - motivate by fear v self motivate; inspect q in verses build it in ...
*** problem of persuing zero defects rather than zero nonconformances. Its ok to ship a product with defects early in order not to miss a market opportunity. This is got to be true else you go out of business though I need to rationalize it ... so need to clearly distinguish between zero defects and zero nonconformances ... dont just put your focus on zero defects, this saves money - it doesn't generate it ....
zero defects is a subset of zero nonconformances ...
no such thing as ballet - Quality is Free p.134. - I don't agree with Crosby except for limited areas ...
*** Need a more structured look at the benefits of TQM: eliminate defects; eliminate hassle; eliminate lateness to market; eliminate missed opportunites; eliminate missing customer requirements ...
need subcommittees by functional area: manufacturing; support; dvelopment; marketing and also by division ...
Mark Levine: "Infrastructure of finger pointing" dev points at marketing for poor reqs spec, qa pts at devf or too many defects, marketing pts at qa for taking too long to fix defects and for taking it too seriously ...
... problem of senior management not liking what they hear from marketing and telling them to go away and look again and sure enough marketing come back with a better analysis - the art of self deception ...
You cannot motivate people to do anything. Its all about self motivation.
The Deming Route to Quality and Productivity. William W. Scherkenbach ...
"Overcoming Organizational Defense" by Chris Argyris. Harvard Press.
Education is teaching someone about something. Training is teaching someone to do something.
2 Books
* Aguayo, Rafael
Dr Deming, The American who taught the Japanese about Quality
Barra, Ralph
Putting Quality Circles to Work
Brooks, Frederick P. Jr.
The Mythical Man-Month
Crosby, Philip B.
Quality is Free
Crosby, Philip B.
Quality Without Tears
Crosby, Philip B.
The Eternally Successful Organization
Cusumano, Michael A.
Japan's Software Factories
(New York: Oxford University Press, 1991)
Davidow, William H.;
Uttal, Bro
Total Customer Service
Davis, Stanley M.
Future Perfect
Deal, Terence E.;
Kennedy, Allen A.
Corporate Cultures, 1982
Deming, W. Edwards
Out of the Crisis
DeMarco, Tom;
Lister, Timothy
Peopleware
Drucker, Peter F.
Managing for Results
Drucker, Peter F.
The Effective Executive
Drucker, Peter F.
The Frontiers of Management
Drucker, Peter F.
The New Realities
Gabor, Andrea
The Man Who Discovered Quality
Gilder, George
Microcosm, 1989
Glass, Robert L.
Software Conflict, 1991
Humphrey, Watts S.
Managing the Software Process, 1989
* Humphrey, Watts S.
Managing for Innovation, Leading Technical People (Prentice-Hall, Inc., 1987)
Imai, Masaaki
Kaizen, The Key to Japan's Competitive Success (McGraw-Hill Publishing Company, 1986)
Kuhn, Thomas S.
The Structure of Scientific Revolutions
(University of Chicago Press, 1962)
Morito, Akio
Made in Japan
Oakland, John S.
Total Quality Management,
(Heinemann Professional Publishing Ltd, 1989)
Pascale, Richard T.;
Athos, Anthony G.
The Art of Japanese Management
Pascale, Richard Managing on the Edge, 1991
Tanner
Penzias, Arno
Ideas and Information, 1989
Peters, Thomas J.
Thriving on Chaos
Peters, Thomas J.,
A Passion for Excellence
Peters, Thomas J.;
Robert, H. Waterman Jr.
In Search of Excellence, 1982
Pirsig, Robert M.
Zen and the Art of Motorcycle Maintenance
* Pressman, Roger S.
Making Software Engineering Happen, A Guide for Instituting The Technology
(Prentice Hall, 1988)
Russel,l J.P.
The Quality Master Plan, A Quality Strategy for Business Leadership, 1990
Schrage, Michael
Shared Minds, The New techniques of Collaboration (Random House, New York, 1990)
Smith, Douglas K.;
Alexander, Robert C.
Fumbling the Future (How Xerox invented, then ignored, the first personal computer), 1988
Toffler, Alvin
The Adaptive Corporation
(McGraw-Hill Book Company, 1985)
Walton, Mary
The Deming Management Method, 1986
Walton, Mary
Deming Management at Work
(New York: G.P. Putnam's Sons, 1990)
Womack, James P.;
Jones, Daniel T.;
Roos, Daniel
The Machine that Changed the World
Zimmerman, Mark A.
Dealing with the Japanese
* Indicates books that I don't own
2 Guidelines for writing this document
Shift emphasis to individual responsibility?
Time ...
Paradigm shift ...
Need to include and emphasise service and support: at the company, group and individual level.
Need a title: Developing Quality Software Products ...
Eliminate jargon.
Use more stories (anecdotes)
Design to make browsing easy.
Put a quoate at the start of each section.
Eliminate all sexism. His, her, girl, man, woman, she, he, ...
*** means a very important concept or idea ...
use my recorder to capture ideas more lucidly ...
Anyone who has been around the software industry for more than a few years has experienced the pressure that managers apply to ship a product by a certain date. It is often the next revision of the company's bread and butter product. It is often already "late" in the eyes of the customers. The product's main competitor has probably already shipped or is about to ship a superior product. Revenues and profits are declining as customer's wait for the new product. Market share is eroding. What's more the current ship date is at the end of a quarter and if the product does not ship in that quarter then the company will be in the embarrassing position of announcing a bad quarter. The pressure is enormous.
So what do managers do, they fix the ship date, they fix the resources, they fix the functionality and say do it. If the development manager or program manager comes back and says its impossible - often the retort will be "don't give me any shit -just do it". Its not always as extreme as this but those of you who have been there know what I mean. In these circumstances, there is one main thing that suffers and that's Quality.
In fact anything that is not directly visible or measurable by senior management suffers. Internally the product may turn out to be a mess - redundant code, un-commented code, spaghetti code. Basically un-maintainable code. So when the next release comes around the job is that much harder. And as the pressure to ship the first release of the product probably had the opposite effect, the second release is late too - and so the pressure and the mess mounts ... continuing loss of product quality and market share ...
One way of looking at this is that the developers "borrow" time from the future to get the product out. Like borrowing money, however, there is interest to pay.
[If a piece of code takes 10 person/weeks to code well, you can code it in 8 person/weeks and borrow 2 person/weeks. If you then need to re-write the code because it is unmaintainable at a second release then it might take you 8 person/weeks to rewrite it (a little less as hopefully a lot was learnt the 1st time around - though only if same person or design/code well documented - actually unlikely!). So 2 weeks borrowed and 8 weeks repaid. That's an interest rate of 400%! That's very costly! Can get into a situation where the product becomes increasingly unmaintanable ...]
Other results: people work long hours and week-ends for many months - they burn out (problem when this becomes the norm)
Why do management do this:
- they don't believe the schedule
- they don't trust their people
- they are not experienced development managers
- they set an earlier date than really needed as they expect the product to slip
- they hope that by fixing the date it will force the team to become creative and only do what is absolutely necessary
Some projects need to be date driven - others not.
What's the solution???
[Management/marketing think that engineers are not business aware and will delay ship to build a perfect product - no bugs -features and functions that are not really needed. Engineers think that man/mark don't care about the quality of the product -they just want to ship and boost revenue this quarter ... A lot of distrust. If engineers are left to their own - the product may never ship - if marketing get there way - it may ship with bugs and other flaws .... Management by pressuring development take away a lot of their motivation to ship a quality product and an attitude of why bother creeps in ...]
1.0 The Flight from ExcellenceTaken almost word for word from Chapter 4, p.19- p.23 of Peopleware by Tom DeMarco and Timothy Lister.
Managers jeopardize product quality by setting unreachable deadlines. They don't think about their action in such terms; they think rather that what they're doing is throwing down a challenge to their developers, something to help them strive for excellence.
Experienced workers know otherwise. They know that under pressure their efforts will be overconstrained. There will be no freedom to trade off resources to make on-time delivery possible. They won't have the option of more people or reduced functionality. The only thing to give on will be Quality. They will push problems under the rug to be dealt with later or foisted off onto the product's end users. They will deliver products that are not really complete; and that cannot be easily maintained or enhanced. Worse still, they will hate what they are doing.
The hard-nosed manager will say "Some of my folks would tinker forever with a task, all in the name of Quality but we need to ship a product and market doesn't care about too much quality. In many cases they are right, but the decision to pressure people into delivering a product that doesn't meet their own quality standards is a terrible mistake.
... continue ...
1 Quality and the Individual
[Place holder]
[Notes: Someone wants some information. So clearly identify the customer(s). Clearly understand their requirements. Ask them if need be. Also ask if there are other customers. Ask when they want it. Ask what quality they require. Ask how much they are prepared to pay for it. ... continue this example ...]
1.0 Notes from Dave Hammond
[Notes]
If everyone in an organization concerns themselves with malking their work easier, they have one person concentrating on making their work easier - themselves.
If everyone concerns themsleves wit making their customers and suppliers work easier, however, then they have many people conctrating on making their own work easier. TEAM WORK.
In both cases, communication is the primary tool to make work easier.
In the first case most communication is complaint. Complaint meets resistance. Lots of frustration. In second case, "how can I serve you better?". Positive response. Mutual.
If just once each day, everyone asked just one of their customers or suppliers "How can I serve you better?" and implemented the resulting suggestion then the pace of improvememt would be ASTONISHING.
2 What other people say about Quality
2.0 Things that need to be in place to win Deming prize
Management committment
Quality circles (quality improvement teams)
Employee suggestion scheme
Statistical methods
Long range plans for continuous improvement
Education of employees
Strong customer orientation
2.0 Crosby's 14 stepsSee p.99, Quality Without Tears, Philip Crosby
Management commitment
Quality improvement teams
Measurement
Cost of quality
Quality awareness
Corrective action
Zero defects planning
Employee education
Zero defects day
Goal setting
Error-cause removal
Recognition
Quality councils
Do it over again
2.0 Deming's six principlesSee p.18, The Man Who Discovered Quality, Andrea Gabor.
1. Quality is defined by the customer. Improvement in products and process must be aimed at anticipating customer's future needs. Quality comes from improving the process, not from "inspecting out" the shoddy results of a poorly run process.
2. Understanding and reducing variation in every process is a must.
3. All significant, long lasting quality improvements must emanate from top management's commitment to improvement, as well as its understanding of the means by which systematic change is to be achieved. Improvement cannot come merely from middle managers' and workers; "trying harder". Neither quality improvement nor long-term profitability can be achieved through wishful thinking and arbitrary goals set without consideration for how they are to be achieved within the context of an organizations process capabilities.
4. Change and improvement must be continuous and all-encompassing. It must involve every member in an organization, including outside suppliers.
5. The ongoing education and training of all employees in a company area is a prerequisite for achieving the sort of analysis that is needed for constant improvement.
6. Performance ratings that seek to measure the contribution of individual employees are usually destructive. Given a chance by management, the vast majority of employees will take pride in their work and strive for improvement. But performance-ranking schemes can impede natural initiative. For one thing, by their very nature they create more "losers" than "winners" and thus batter morale. And since they don't take into account natural variation, they are inaccurate and unfair, and are perceived as such by employees.
2.0 Deming's Fourteen PointsSee p.17, The Man Who Discovered Quality, Andrea Gabor.
Establish constancy of purpose
Improve constantly and forever every system of production and service
Eliminate numerical goals and quotas, including management by objective
Drive out fear so that everyone may work effectively for the company
Institute leadership
End the practice of awarding business largely on the basis of price
Break down the barriers between departments
Institute training on the job
Eliminate the annual rating or merit system
Institute a vigorous program of eduction and self improvement
Eliminate slogans and exhortations
Cease dependence on mass inspection
Adopt the new philosophy
Create a structure in top management to accomplish the transformation
2 Resource Material
Everything in this section is a mishmash of resource material in various stages of formation and completion.
2.0 The importance of time
More haste, less speed.
It is a mistake to think that if you work faster, you make more time.
Time is a serious problem. There is never enough of it. There is never enough time to do anything right. There is never enough time to do everything that needs to be done. This means that everything is rushed. It means screw ups, hassle and rework. This in turn reduces available time. Which means panic, more hassle and more rework. This is a vicious spiral.
Improvement in the management of time is fundamental to improving Quality in a software manufacturing environment.
2.0 Engineers and MBAs
Practically all of our major corporations were started by technical men - inventors, mechanics, engineers, and chemists, who had a sincere interest in quality of products. Now these companies are largely run by men interested in profit, not product. Their pride is in the P&L statement or stock report.Quote from p.131 Out of the Crisis by Edwards Deming.
2.0 Who is an executive?
Every knowledge worker in a modern organization is an executive if, by virtue of their position or knowledge, they are responsible for a contribution that materially affects the capacity of the organization to perform and to obtain results.See p.5, chapter 1, The Effective Executive, Peter Drucker. This chapter goes on to make a lot of awfully good points.
2.0 SEP Fields
[Notes: This story told by manufacturing guy on Aren's committee. Concept of SEP (someone else's problem ) field - lift the quote from Hitchhiker's Guide to the Galaxy ...]
Manufacturing often face the problem where development misses its planned gold date by several weeks and the golds are eventually delivered late to manufacturing. The planned manufacture of that product may then clash with another product going gold at the same time.
rather than complain and blame onto product development
1) Improve flexibility - its always going to happen
2) Product development is Manufacturing's customer. Therefore it serves no useful purpose to complain and bad-mouth. You need to talk to help them solve their problems (joint problem).
its the way you look at it - their problem or yours - often its yours as much as theirs
2.0 The ripple affect
In the world of information and ideas, incomplete or defective information upon which other information is built or concepts are based is a killer. This is because of the ripple effect. The defective information or idea ripples through everything that follows it causing untold damage.
[Need some good examples here!]
2.0 Artists, Scientists and Engineers
[Notes]
Many developers think of themselves as artists ...
A true artist works for themselves. They have no concept of customer other than themselves ...
An artist is like a fundamental research scientist - they deal with paint and clay, a fundamental scientist with conecptual models of the universe (Newton, Einstein ...). They are not customer oriented.
Different types of people and activities:
1) pure, fundamentalists - academics if you like, artists, poets?, the pursuit of knowledge for its own sake ...
2) applied research, technologists: directed research, silicon phsical properties aimed at improving semi-conductor technology.
3) technologists - refining existing technology, ideas etc.
4) engineers - product developers - the folks producing consumer items
Software engineers who consider themselves artists should be in the research labs - not working on a product team.
See Kuhn and Software Conflict - chapter on problem solving.
2.0 Customer Deliverables
The things the customer sees:
. products, services
. press articles (no direct control only influence over this)
. collateral
. advertising
. people: customer service, sales force, marketing people
. trade shows
2.0 Quality Relationships
[This section is an unedited brain dump. It needs a lot of work.]
2.0.0 Getting Things Done
If you wish to do something and you have the authority and control over the resources that you need then you don't have a problem you can just get on and do it. If you don't have the authority or control, then you will need to persuade someone else to give you the resource or to do it for you. (Often only the other group can do it ..)
Lets suppose that you wish to see something done, a particular "internal supplier" needs to do something to better meet your requirements. Well that's easy - you go to the General Manager of that group or some other appropriate level, explain your requirements; they listen; understand and agree to do everything that you ask for!
[something about selecting the level to approach - the individual worker, their boss - the GM of the group - depends on the scope and impact of the problem (requirement) ...] Also its not what you do when you ask but everything you ever did in the past that makes the difference between a yes and no answer.
On the other hand, given day to day pressures, you may get little or no time from the person you approach, you may even get a very categoric NO or maybe get a "yes" that means -
No. ("I won't do it.")
Yes. ("I will do it.")
Yes. ("I'm too smart to say no - but I've no intention of doing it.")
Yes. ("I will do it." I want to do it but in reality they are fooling themselves - they can't deliver - they haven't got the time or resource to meet your requirements - i guess the real commitment is not there - this isn't deliberate it s just a human failing.)
The real issues - if you want to get things done - is to say -(like any good guerilla fighter) - what have I got to do in this particular situation - to WIN - try the GM, try the development manager, try the product architect, try the program manager - try the new programmer - find anyone in the team who will listen -influence them.
2.0.0 Battles
Do not fight battles that you stand no chance of winning - how ever worthy the cause. This is a major mistake that many people make. They feel that they are being untrue to their beliefs or not doing all they can for their company by not championing what seems to them clearly apparent wrongs.
If you fight a battle that you lose, you do many things: it depresses you; it destroys your reputation; you lose credibility; it causes your judgement to be questioned (wasn't it obvious that cos of pressure to ship - that couldn't be changed). Also, in fighting the battle you make enemies - you destroy relationships for ever. Not just ones that you have but ones that you might hope to make in the future - people will not want to associate with you.