Posts Tagged
‘risk’

We have a running discussion with some project managers and line managers on the topic of responsibility.  The organization structure is matrix (weak) with seeming aspirations to strong matrix.  The project managers attempting to drive the project are frequently confronted with the line management saying – “it is our responsibility”, or “trust us to deliver”. […]

My work experience informs me that the loss of slack is a big risk to projects. Without this wiggle room, we reduce our probability of success. Projects scheduled out to the last available date just do not work. The reality is these are not manufacturing or routine tasks and jobs. Even the rather routine tasks […]

Our risk exposure starts at the beginning of the project. Even before the project is actually a project.  The simple act of scoping a project in the initiating phase already alludes to the risks to which we may be exposed. For example, the minute we decide that our project scope is going to include software, […]

Sometimes it is difficult to speak up when you know you have problems. Not many people want to be the person who is perceived as holding up progress, probably a self-preservation mechanism.  However, when it comes to project work and teamwork, we can ill afford to play such games.  Enter the game I call “product […]

The team works toward an objective of developing and releasing software according to a schedule.  The delivery date comes, and the team has not achieved the objective.  The project manager is at a loss for words. What happened? The team then informs the project manager – “we always said the time was tight”.  The team […]

The daily sprint meeting has connections to our risk management as well. We have seen from the previous posting the fact we are having the meeting daily can hasten our project’s (system’s) ability to respond.  The sprint master is now asking about the obstacles or impediments to achieving the objectives of the sprint. Impediments and […]

We break form our blog run on sprint meetings due to incoming flambé du jour. Sometimes we see organizations that are afraid to use the most fundamental of tools, for example, fault tracking from verification.  Instead of using a tracking and visibility tool, we pass back and forth excel sheets behind the scenes. Why would […]

            We strongly recommend automated testing whenever this approach is feasible. The test team can use a language designed for this kind of testing; for example, the National Instruments product Labview. The software should be able to read in the documented test cases, execute the test cases against the product, and finish by producing a […]

With fifth dimension testing, we use techniques more commonly employed by the “bad guys.” For example, we may execute techniques such as: Fuzzing Response modification using genetic algorithms Input breakdown Overflows Underflows This approach allows for evolution of our test collection. We can automate a significant number of these tests if we have a comprehensive, […]

            Extreme testing occurs when we deliberately “torture” both the hardware and software to see what happens under undesirable conditions. Some examples of extreme testing include: Random voltages within the allowable voltage boundaries Voltage slews Deliberately introduced random noise on the data bus Extremely high bus loading (over 80% and sometimes over 90%) to see […]