One under or ineffectively used tool is the specification or requirements review, which is a form of design review. In this case we are reviewing the design while it is still easy and cheap to make adjustments. Experience suggests, if we do not just forget to do this activity, it is a hastily arranged activity […]
You need not been so technically skilled to be able to see how many project fail due to requirements. We provide a brief list of the failings below: Requirements control Insufficient time Did not include the sponsor or customer Late delivery of requirements Requirements traceability We will not write any more on requirements control that […]
The initial product requirements provide the product baseline. Our project planning will be focused upon delivering meeting these requirements. In a phased development process, we will prioritize the requirements (shown earlier) and deliver iterations. This staged delivery allows us to gain additional insight into the product. We may learn things that necessitate changes to the […]
So how do we ensure we get meaningful requirements? We have a number of ways to understand our objective and learning about the Interviews customer clinics Simulation Digital mock ups Prototype physical mock ups Instrumentation Other information gathering (standards, regulations, etc.) We start with interviews of customers, stakeholders and project sponsors. Interviews also include customer […]
Occasionally, we are put in the position of removing an employee; that is, we must fire them. In many cases, we will not have enough documentation to validate the ineptitude of such an employee. Furthermore, we may not have a standard algorithm (procedure) to follow when removing this individual. Many companies add the impediment of […]
Creating a separate software test group has pluses and minuses. At a minimum, we may have more to manage. Some of the minuses are a product of human nature. When we know our work will be inspected, we will often assume the inspector will catch issues and we pay less attention to the issue ourselves. […]
We have been on a bit a tear (or rant) about FMEAs. We suggest the FMEA documentation is part of the core of a design process. The ultimate approach we have seen is that of Michael Anleitner (The Power of Deduction: Failure Modes and Effects Analysis for Design, Quality Press, 2010), which uses functional analysis […]
There is only one way to describe this scenario and that is via a story. Consider the organization that is coming to the end of the project. The product is a complicated subassembly that goes into a larger system and has numerous interactions and incarnations of the design. They are late in the delivery of […]
Risks can have origins in communications and are not the sole province of the stakeholders and sponsors of the project. Sometimes the organization damages itself via the structure. We are all familiar with the functional organization, often referred to as a line organization or stove pipe organization in which we group the company by discipline. […]
This blog post is born out of a response to the Named Risk post from Ed Arnold on www.LinkedIn.com. He left the reply below: In my experience, a lot of time/effort is wasted when project owners change. The knowledge gets lost, even if they leave their spreadsheets and power points behind. The answer: a collaborative […]