I really haven’t posted all that much recently.  Mostly its due to
the fact that I’ve been stressed at work and probably wouldn’t have
posted anything constructive.

The short of the past weeks is that I’ve been stuggling with completing
the Data Model to Bind Them All.  Finally the battle has started
to slow.  Sadly this is mostly due to the fact that Grima has gone
on holidays.  I’ve been trying to figure out why the process of
getting the models approved has been such an epic struggle.  I’ve
only thought of a few things.

One of them is that I did not produce the quality of deliverable that I
should have.  I will admit that there is truth to this
statement.  I certainly should have spent more time working on the
finer details of the product.  I should have created a step in our
process for creating the deliverable which was “Export report to RTF
and run through the MS Word spell and grammer checker.”  I should
have spent half an hour reviewing the final report that I created for
the deliverable, and this should have happened every time that the
deliverable was created.  When I finally got access to the
application that stores the “approved abbreviations”, I should have
started over and reviewed every aspect of the model.  So, fine, I
was to blame for some of this debacle.

The other major problem that I’ve determined was that there was a major
disconnect in the communication between our team and Grima. 
People, you don’t understand the scope of this problem. 
MAJOR!  Communication directed at us mostly consisted of vague
statements such as “There are many abbreviations being used that aren’t
approved”.  Okay, this may be true, but can you feed us a
bone?  Maybe just one example?  There also was the problem of
not knowing what procedures Grima wanted us to follow.  There is a
process for the review and approval of these deliverables.  Both
review and approval have a number of different people who must sign off
on them.  Our process was review for a certain specified number of
days, absorb the comments, clarify them, make the changes and finally
send for approval.  I did this only to have Grima get upset and
ask that we issue an interm version, to him alone, so that he could
approve it prior to us releasing the changes to the rest of the sign
off people.  We also dropped the ball by saying that we would make
changes and would send the “interm” version to Grima when completed,
and then we missed sending it by three hours.

Now for the last problem.  I hate to say this was an issue, but it
was.  Grima has no technical skill in data modelling.  When
changes to cardinality, normalization and relationships arose they did
not come from the Data Architect.  Instead the only conversations
that I had on these subjects were started by the Business
Analysts.  Instead of focusing on approving the structure of the
models first and then riding us to produce a deliverable that met his
standards, Grima decided to reverse this and firstly concentrate on
producing a clean deliverable.  Once we had been in a few meetings
with Grima we realized this and one of the people on my team decided
that the best approach to solving this was to clearly state to Grima
that, although his issues were very real, we needed to get the “real”
issues resolved or he was going to stop the project and begin pushing
the delivery date of the software.  This definitely achieved the
result desired and the correct order of importance was acheived.

I have to say that, although it was stressful (see the sign on my
window stating “No Jumping Zone”), I have learned a lot from
interacting with Grima.  I just hope that he picked up a few data
modelling pointers from me.