Information Technology Reference
In-Depth Information
...
Kinds of Risks
Most aspects of your project pose risk for the project. If you have a shortage of
resources, then you have a risk. If skills required for the project are not avail-
able, then you have a risk. If too many changes are being requested, then it
poses risk. If there is a misunderstanding within the team or with a customer
or subcontractor, then it is a big risk for the project. You name it and you have
risk out there!
Let us see some common risks that every project faces.
6.3.1
Communication Risks
Communication risks pose the biggest risks on any project. They have an adverse
impact when the project is outsourced. They have a severe impact when the project
is offshored!
It cannot be emphasized more than if we say that 60% of the success of the
project depends on good communication. If requirements and change requests for
requirements are well understood, then the design of the software application will
be good. This will lead to good coding. The standards like CMMI and ISO have
always placed more emphasis on communication than on any other aspect of proj-
ects. Poor quality often results from poor communication.
In essence, poor communication is the single biggest risk on any project. When
it comes to test projects, the test team must have good access to requirements and
design documents as well as access to coding documents. If most of the commu-
nication on the project happens to be verbal and no written documents are being
prepared or being followed, then it will be difficult for the entire test team to per-
form well in their respective assignments. Written communication must be applied
for all test activities.
6.3.2
Effectiveness
In the initial assessment many people are happy only with the volume of defects
reported. In reality, however, the effectiveness of the test team is determined by the
number of must-fix defects reported. Trivial or cosmetic defects do not impact any
software application. But critical and must-fix defects do.
The test manager must ensure that the test engineers understand the implica-
tions of less-than-expected effectiveness of the test team. When users start logging
critical defects after deployment, the test manager should be prepared to answer for
less-than-effective testing done by his team. Ineffective testing costs a lot of money
to the software vendor. Unfixed critical defects that are to be fixed after deployment
not only cost big money but also dent the confidence of users of the software appli-
cation, and this in turn results in the poor image of the software vendor.
