Information Technology Reference
In-Depth Information
review and/or product verification. I have suggested this because I have
often heard frustration regarding “
hard rules
” that don't seem to make sense
in certain situations.
What I have suggested is that projects document
criteria
and provide written
authority through its project plan to a project leader to make peer review and
verification decisions based on that criteria.
While I often recommend this, let me give you a caution. One organization
followed my guidance and created the following criteria for when a peer
review could be waived:
•
Experienced, proven developer
• Low risk change
• Minimal impact to other systems
• Developer working closely with interfacing, dependent personnel
The assigned project leader became busy, and delegated this criteria to his
team. When we examined the project later we found that no peer reviews
were taking place because all involved were deciding they were experienced,
proven developers, their work was low risk, they were working closely with
dependent personnel, and there was minimal impact to other systems. There
are two lessons here.
First: Project Leaders should
NEVER
delegate such criteria.
Second:
LESSON 7
Criteria can be abused. They can help an organization that desires to
increase its agility, but there is responsibility and training that must go along
with agility.
CAUTION
Keep this story in mind as you decide whether your organization is ready
for the use of
criteria
. Your people need to be ready, too.
The subject of people readiness for
agility
is the primary topic of the DART
case study in the next chapter of the topic.
