Information Technology Reference
In-Depth Information
was reasonably good to the level they had defined it. For example, in the
Te c h n i c a l S o l u t i o n a re a i t s t a t e d t h a t a d e s i g n a r t i f a c t m u s t b e d e v e l o p e d , a n d
reviewed. However, as I examined their artifacts in greater depth I found no
specification as to what content needed to be in that design artifact. Without
this information, any person assigned to develop or review a design artifact
would not know what to place in the document or what to review it for.
What GEAR needed were improvements in the area of
criteria
, and
product
templates
.
I discovered a number of templates that had been developed within the soft-
ware organization at GEAR. However, I found few of them actually being
used. I asked questions to the workers at GEAR such as:
• Are these templates required?
• Is each project allowed to tailor the templates, and if so, who approves
the tailoring?
• Is there a minimum that each design artifact must contain that cannot be
tailored out?
The answers I received to these questions were inconsistent and weren't
written down or agreed to across the organization.
7.6 Writing Processes for People in “My Department”
At GEAR, I observed patterns similar to the “cookie cutter” processes at
NANO. However, the reason it occurred at GEAR was different. At NANO,
many held the misguided view of process as relevant only for work that had
no uncertainty associated with it. At GEAR I observed a lack of stakeholder
identification (similar to NANO), but in this case it appeared to be the result
of a desire within each department to ensure they could control the activities
in the process within just their own department.
GEAR was a small organization structured like many large organizations
with distinct software, systems, hardware, and test departments. When the
MSG asked these departments to define their processes, each primarily
looked inside their department (“my department”) and didn't adequately
consider interfaces and dependencies with the other departments.
I observed this in the way they wrote their processes, and how they exe-
cuted them. One senior systems person said it was not uncommon to go to a
