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 […]
Over the years, we have heard executive level individuals cry out for cultural change in their organizations without understanding the ramifications of what they are saying. With cultural transformation as usually touted, we are talking about massive levels of upheaval. The upheaval approach can be counterproductive if it does little more than produce a culture […]