Quality management
Soon is not a time
Sat, 10/25/2008 - 09:32 — Bryan PflugProcesses, Mental Models, and Improvement Dynamics
The word process is an abstract concept. As a result, its meaning is often dependent upon the context in which it is used, and the mental models of those who are using the term. The dangerous part of this is that people can carry on conversations about them, and believe that they are talking about the same situations, even though they are actually discussing several, fundamentally different things. As a result, they each can think that they are communicating about the same 'process', and can go away from that conversation with the mistaken impression that they all agree on something meaningful, or all have a shared vision of what it will take to transform something. What is really going on is that consensus is typically achieved by adding ambiguity, rather than removing it.
As an example of these different 'mindsets', consider the following: read more »
- Bryan Pflug's blog
- Login or register to post comments
What does it take to achieve consistent outcomes?
Sat, 12/15/2007 - 08:23 — Bryan Pflug
It seems obvious, but deserves emphasis: consistent outcomes can only be achieved if there is control of:
read more »
- Bryan Pflug's blog
- Login or register to post comments
How does one learn a lesson?
What is a lesson learned? Simply put, it is is knowledge or understanding gained by experience (whether positive or negative), and which adds significant, valid, and relevant new information that would be useful in accomplishing a business objective.
read more »
- Bryan Pflug's blog
- Login or register to post comments
Software Program Manager's Network
The Software Program Manager's Network (SPMN) was established in 1992 by the Navy to identify proven industry and government software best practices and convey these practices to program managers of large-scale DoD system acquisition programs. By sharing and applying such "in the trenches" experience, the SPMN enabled these program managers to achieve improved program success and deliver quality systems on schedule and on budget.
read more »
- Login or register to post comments
- Visit Software Program Manager's Network
What exactly does having a 'requirements problem' mean?
Sat, 09/01/2007 - 06:19 — Bryan PflugThere are often many findings and discussions in which people attribute failures of a system, or of a project, to 'requirements problems'. It is not always clear what they mean by that, but it is important to think carefully about the many different kinds of things this could mean, and recognize that each of these different situations requires a different solution, and has different implications.
These assertions are often not performed within a well-formed definition of what a good requirement is, but it can be a convenient shorthand for saying 'I didn't understand', or 'Someone should have told me', or 'I didn't have time to explore all the possibilities', without having to take.
I believe it is human nature to avoid dealing with personal failure. As a result, if you ask them 'was it your responsibility, or the responsibility of someone upstream of you', people want to naturally avoid being found 'at fault'. This is basically human nature. read more »
- Bryan Pflug's blog
- Login or register to post comments
How should we then build?
Sun, 08/26/2007 - 07:27 — Bryan PflugIt's all about software engineering.
For areas where high reliabililty is key, it's also about well-formed test coverage completion criteria.
(to be continued)
Why do we test?
Sun, 08/26/2007 - 06:01 — Bryan PflugPeople often forget that it is impossible to demonstrate the absence of something. We do not test to demonstrate the absence of errors. We test to find errors, and to show what works
(to be continued)
Why is testing software different than testing mechanical devices?
Sun, 08/26/2007 - 05:57 — Bryan Pflug
Why test software at the software level itself, rather than just in the context of the system the software is embedded in?
- software exists only as part of a system
- software is invisible, intangible, abstract
- there are no physical laws underlying software behaviour
- there are no physical constraints on software complexity
- software never wears out
- traditional reliability measures don't apply
- software can be replicated perfectly
Handling product introductions with care
Sat, 07/21/2007 - 11:06 — Bryan Pflug
When a highly anticipated and popular new product like Windows Vista is released, over the course of it's first few months in the field, tens of millions of users can rapidly migrate to it and begin to use it. Their 'first impressions' will have a profound impact on the future success of the product.
When such a products are large and complex - and especially when they are software-intensive - there are three simultaneous trends underway during this period. First, many on the team which has been working on the product while under development will begin to move to new assignments, or take on new features for future releases or products (especially the most highly rated members of the team). Second, the number of hours of execution per day that the product's code base is being subjected to grows exponentially, thus increasing the likelihood that latent problems will be uncovered. Third, your call center personnel (because of the need to spin up large numbers of new people to provide support) will likely have less knowledge and experience than at any other time in the product's lifecycle. This is a knowledge management challenge for the development and support team, to say the least, as well as a stress on the maturity of issue management processes. read more »
