A loss for Meridian last month.  Another consultant passed away suddenly.  This time though, there was not a large network of friends grieving over the loss.  This was a quiet consultant, who seemingly had little interaction with family or friends outside work.  

Chris first worked for us back in 2005.  He had been on contract for a few months when an opportunity to convert to full-time status came up.  Chris pursued that opportunity, but for whatever reason it did not materialize and so, his contract ended and he moved on.  A short while later, he came back on board for a contract with another client.  He stayed for a few months until that contract ended sooner than anticipated. 

The last time that Chris would return to work for us was in April of 2007.  This last assignment was rather a challenge for Chris due to the chaotic client environment and lack of control.  I sat next to Chris at lunch in mid May.  Although never talkative that I observed, Chris sat quietly through that lunch, listening to some of the other consultants describe some of the challenges and perks of working on their assignments.  He hunched over his plate and seemed to sink in on himself during the meal. 

Chris called me in July.  He had read the Meridian newsletter and was disturbed to hear that one of his former coworkers, Alfred, had recently died.  I told Chris that Alfred had left work due to illness and never returned.  Chris could not believe it.  That was the last time I heard from Chris. 

The first time I interviewed Chris, he told me that he did not do well on interviews.  He said that he often had trouble with people when he first met them, but usually after one or two sessions, things would work out fine.  Although shy and reserved, I think Chris was well regarded by his peers.  He apparently thought highly of his coworkers too.  In one case, he even purchased a lamp and brought it to a coworker who had complained about how dark it was in her cube.  Perhaps the world has grown a bit dimmer without him.

Reviewing resumes can be interesting, boring or downright frustrating depending on the content.  I like to see resumes that describe what people have accomplished with technology, particularly if they are able to quantify their results.  I dislike resumes that rely on buzz words to get the point across.  But the resumes that really tire me out are the ones with typos, errors and incorrectly rendered tool names.  If you can’t spell it, do you really expect me to believe you are an accomplished practitioner with that tool or technology?

I never considered project management to be a religious calling, yet many project managers seem to end up as mangers.  I can really appreciate those who are able to maintain strong relationships with piers or those with stung team building skills.  Of course, who couldn’t admire a versatile systems administrator who has experience with the full gambit of platforms?  And do people really believe it’s HIPPA to be so concerned about the privacy of health data?

I can sympathize with business systems analysts who struggle to get sigh-offs after user acceptance testing is complete.  And let’s not forget the data warehouse specialists who are forced to deal with business inelegance.   Oracle tools have never been practical for sensitive types, but don’t you think those who work with SQL*Pus deserve a medal?

Yes, I think it’s fair to say that I am n-tired of reading bad resumes.  And if things don’t get better, I may end up in n-tears!

These days, when a consultant fails to report to work without notifying somebody, you think that maybe the person was too ill to call in.  Or perhaps the person had to drop everything to take care of an aging or seriously ill family member.  Once in a while, a careless person will need to be reminded of how important it is to notify the client and the employer of an unexpected absence.  Once in a blue moon, it's something worse...the consultant has died.  And that is just what happened last month. 

Just two months after I met Alfred for lunch, he was gone.  It was a pleasant lunch where we discussed Alfred's ideas about expanding his technical skills to include Java.  He loved working in Portland, Oregon, but was concerned that there might not be enough .Net work to keep him gainfully employed.  I encouraged him to work on his training plan to find a course and some materials that would help him branch out.  Of course he did so and received approval to attend a course scheduled for later this summer.

We discussed other things at that lunch.  His recent trip to Malaysia to visit his family.  A question he had about timesheets.  The weather.  Healthy foods and lifestyles.  An enjoyable lunch with a gentle man.  Alfred was an intelligent, dedicated professional.  He will be missed by many at Meridian. 

Have you ever worked for a client organization that featured a great divide between IT and the business units?  Or even worse, a place where IT personnel were ridiculed because of the unfortunate decisions of the CIO?  Over the last 2 or 3 years, our client base has increasingly demanded project managers and business systems analysts to assist with project efforts that have failed or been back burnered for too many years.  These resources are expected to be PMP certified, strong with RUP or other tried and true methodologies.  They must be familiar with as-is/to-be business process analysis and equally capable of conversing with end users, corporate wigs or software engineers.  Their charter is often to hit the ground running in a search and rescue effort.  Searching for ways to define and document business requirements while they patch up faltering relationships and rescue failing projects.  And let's not forget their impossible mantra: on time and under budget. 

On occasion, the resources needed are expected to come in at a higher level to establish a roadmap for the enterprise.  These business process engineers face the challenges posed by an uneasy truce between the business and the tools.  They deal with conflicting directives and opposing agenda on a daily basis.  In their spare time, they check their body armor for dents.

Could it be that these business systems analysts, project managers and business process engineers will usher in a paradigm shift that replaces the IT allure with the fastest server or slickest new software with a methodology that truly is agile?