I guess officially we'd call this a "weak" matrix, but one thing works to my advantage.  I'm fortunate that the culture of our company places value on the major role that projects play in the organization.  Project Manager is generally a "strong" position in this culture.

A Strong Project Culture

Team members understand that team participation and success is a significant portion of their job function.  I certainly encourage team members to identify with the project, take ownership of their part, and build relationships between team members that lead to them wanting to perform well on the project.  At the same time there's an implicit expectation that the team member will complete the tasks to which they're assigned. 

I believe people want to do a good job.  They want to be recognized as a valuable, contributing member of their business and receive whatever rewards come along with that, intrinsically or extrinsically.  In this culture, I find it's just not that hard to maintain productive, respectful relationships.  Professionalism, recognition of the team member's expertise, social interaction (even on virtual teams), and simple human decency go a long way.

I don't want to make it sound all rosy.  There have been times where work wasn't done and I had to escalate the issue to the functional manager or higher.  Right now I'm leading a project where a team member has to carve project work time out of his normal daily functional support activities.  We're refreshing a number of servers, and we're running into schedule problems on the first one as a result of this team member being pulled in more than one direction.  In the past, I've also worked with functional managers to have team members replaced who, for whatever reason, couldn't do the job.

Forming, Storming, Norming, Performing

In an article for the Washington DC PMI chapter, Team Building and Development in a Matrix Environment, Karen Davey-Winter writes, "Keeping a diverse group of people together in a matrix team depends on building loyalty and trust."  She describes over a dozen techniques to do so and relates how they can be used in relation to Tuckman's five stages of group development (Forming, Storming, Norming, Performing, Adjourning).  Her suggestions include holding kickoff meetings, using team building techniques, and defining delivery processes. 

If your company doesn't have a strong project culture, her ideas can be helpful.  And if you do have a strong project culture, you have even more tools or advantages at your disposal.

Now that I'm past the cuteness of it my mind starts wandering every time I see it, and I've noticed they leave out some key information regarding their restaurant.  Number one, they don't mention whether or not the food actually tastes good.  They make it very clear that the food is cheap.  And although they don't mention it, since GC is a buffet style place it would be tough for another restaurant to beat their speed of service.  But what you don't see is customers closing their eyes and moaning in ecstasy as a result of the Golden Coral chef's culinary expertise.

Cost, Quality, or Price, Which Two Do You Want?

Apparently at Golden Coral, you can satisfy your schedule (speed of service) and cost (10 bucks) requirements, but the third leg of that triangle (quality) comes up short.  It's a classic case of the triple constraint in action.  A Google search returns about 195,000 hits on the triple constraints of project management so I won't go into a lot of detail here. 

I will say the triple constraint is a somewhat specific view of a project in terms of three factors, generally Cost, Schedule, and Scope, though you can see in the diagram the three legs of the triangle sometimes have different names.  The way it works is that by changing one of the three constraints, the other two are impacted.  For example, I can deliver a project faster (shorter schedule) but that might mean more cost or fewer features (Scope).  I can include more features, but that might mean more cost and a longer schedule.  Or I can decrease project cost, but it might mean more time to complete or a lower quality product.

It's Working All the Time

The fact that I thought of the triple constraint while watching a TV commercial was somewhat surprising for me.  Even though -- or maybe because -- I know the triple constraint applies all the time, I don't routinely think about it during the course of my projects.  It's always there; it always works so I don't spend a lot of time considering it.  I take a more systemic view looking at the project as a whole, are we delivering the appropriate value, how the risks impact the schedule and budget and resources, or how the customer perceives our progress and do I need to take action on that.

I believe the triple constraints are so ingrained in our thought processes that we weigh them almost automatically in every project related decision we make.  Still, there is value in recognizing the interrelationships between the various aspects of your project.  We have to be aware that changes aren't made in a vacuum.  When we change one aspect we likely impact another.

If you want a great tasting steak maybe Del Frisco's is a better choice...but you'll probably sacrifice your schedule (since it'll take longer for them to cook the order to your specifications) and a lot more money.  The question becomes, what is the best thing for your customer?  What is the best thing for your project?  Which combination of price, schedule, scope, quality, risks, resources, etc. will provide the most value?  Knowing how the project elements are affected by one another is key.  And you can't get that for just 10 bucks.

Why a Bonus?

The reason I'm writing this bonus post is that I attended our PMI chapter meeting tonight (Space Coast, Florida), and we had Rick Morris speaking to us.  Now Rick doesn't need my endorsement, he's doing quite well as an author, speaker, and consultant with no help from me.  But Rick is clearly a passionate individual and that passion carries right over into project management.  I'm good at getting pumped up about something when someone else is obviously pumped, and that describes Rick tonight.

I haven't seen Rick before and he had to trim down his talk with us since we cut him short on time with our chapter business, but he's one of those guys you can listen to for hours.  I went straight home to check out his blog, PM That Works.  His articles read like he's standing there talking to you, and some of the examples and stories he used in his talk were also posted or referred to in blog articles.  One that wasn't though is an article I found near and dear to my heart, the value of project management.  His article, Determining Business Value for Projects, is the text of what he wrote to a client about their new Portfolio Management Committee and what they should do and what they should measure to get value from their project management.  It very plainly describes factors they should consider and provides a great template for anyone interested to get started down that path.

Thanks for the great talk at our meeting tonight, Rick.  I'm looking forward to hearing you again.

Soon after I completed the paperwork, I got my first monthly statement from the new company.  As I hoped, all my money was there, which was my primary concern.  The name of the financial management company that my IRA was transferred to was correctly listed on top of the statement, which was nice.  And in the upper left hand corner of the statement was a big bank logo.  The problem was, it wasn't my bank's logo!  It was a little confusing, but since my money appeared to be correctly recorded with the investment house that I was moved to, I didn't pursue the issue.

Just a few days later, I got yet another letter from my new financial management company signed by the Senior VP of Operations.  "We value every customer...high standards for customer service...very disappointing if we fall short" blah, blah, blah.  But surprise, surprise, the last sentence in the first paragraph:

"I would like to take this opportunity to extend my sincere apologies for our failure to meet the standards of performance you deserve and that we demand of ourselves."

The letter went on to explain how they had messed up "due to a processing error" but that "the error was limited to the use of the wrong logo."  They wrote that my personal and financial information was not shared with anyone else, the issue has been corrected and the next statement will have the right logo on it, the error should not reflect on my bank, "trust is earned," "continuous improvement," and a phone number for any questions.

Overall, I thought this was a near perfect apology.  I didn't think the original error was a big deal, but I only had one little IRA with them.  I'm sure they got unending grief from 80-year old grandmas who have their life savings with these guys and from privacy paranoids.

Sorry Seems to be the Hardest Word

Since everyone makes mistakes, what can we take away from this from a project management perspective?  Imagine that you leave an important stakeholder out of the review and approval process for a key document, or maybe you include them but then inadvertantly leave their comments out of the updated document.  The stakeholder is offended and angry.  What do you do?

1.  Apologize.  Let them know that you realize you made a mistake, it wasn't intentional or personal, and you're genuinely sorry for doing it.  Express some contrition and a little embarrassment.  In addition to the apology in the first paragraph, the Senior VP wrote, "The printing of the incorrect logo should not have occurred and we apologize for any concern or inconvenience that it has caused you."  These are good apology statements: they don't blame the offended party or someone else, they accept responsibility, they recognize their error.

2.  Explain.  Tell the offended party what happened.  Don't be tentative or try to cover up an embarrassing gaffe.  Don't make excuses.  Just come out with it.  The investment company letter explained that my bank's statements had been printed at the same time as another bank's statements leading to the printing of the wrong logo.  A straightforward explanation without sounding like an excuse or a cover up.

3.  Reassure.  Let them know everything is fine, assuming it is.  Don't leave them wondering.  For example, the VP wrote, "Your information was not inadvertantly shared with any outside party" and "This issue has been corrected and your January 2010 brokerage account statement will reflect the correct logo."  They took ownership of their mistake and made me feel better about it.

4.  Correct.  If everything is not yet as it should be as a result of your mistake, let them know how you plan to fix it.  If you left out your stakeholder: "The revision of the Transition Plan that we released yesterday now includes your comments" or "We plan to issue a new release of the Transition Plan next week and it will include your revisions."

5.  Contact.  Be sure to include some way to contact you if they have any questions or other concerns or they just want to vent.  This is critical because otherwise you're sending the message that your apology was just lip service and you don't really care about their concerns.  My friendly VP invited me to "contact the Company Service Center, 800-xxx-xxxx option 2, or your Financial Advisor."

An Even Better Apology

I didn't expect that letter from the broker, but I was satisfied that they were genuinely sorry and had fixed the problem.  Even so, I found some things I might have done differently.

• Apologize first.  The apology in the letter didn't appear until the last sentence in the first paragraph.  I think it would have been better to make the apology the first sentence.  Give it the prominence it deserves, and don't leave the recipients wondering why they're getting this letter.
• Personal is better.  It's tough to express a sincere apology in a mass mailed letter, but this mistake was relatively minor and a lot of people had to be apologized to so a more costly personal approach was probably not appropriate.  However, if the mistake warrants it, a face-to-face discussion is best.  Other options (in decreasing order of effectiveness) include a phone call, a personal e-mail, a personal letter, and lastly the mass mailing I received.
• More contact options.  Calling the 800-number customer service center is near last on my list of contact preferences.  What about an e-mail address?  A web site where I can express my anger?  I wouldn't mind contacting this VP just to say I appreciate the apology and he did a good job.
• The right person.  The Senior VP of Ops seems to be the right person to apologize in my case.  It was an operational mistake after all.  But make sure the right person says they're sorry.  CEO?  Chairman?  Printer?  I don't want an apology from someone who was just doing what they were told.

What do you think of all this?  Do you have experience with apologizing or being apologized to?  Share your thoughts about the right way to say "I was wrong."

This is a problem for me for two reasons.

1.  There's a good possibility that the team members or stakeholders that I'm not talking to have information that can benefit the project.  As the project progresses, we focus on the areas that need the most attention and tend to neglect those that are doing OK or are simply not active at the time.  The problem is that if a person is not involved or active on the project, they might not be aware of the current status or problems we're facing.  If I don't talk to the people I won't get any information they have that might be able to help resolve open issues.

2.  The longer I go without speaking to this person, even if it's justifiable, then

• the person feels less a part of the team
• the person becomes less willing to participate when their input is needed
• the more likely it is that the person gets significantly involved in other tasks outside my project limiting their availability to support my project

To help address this problem of lack of communication, I'm making a conscious effort to speak with someone each day who I don't normally come into contact with during meetings or other conversations.  For many project managers, this probably doesn't seem like such a big deal, but it is to me.  Striking up a conversation with anyone goes against my natural introvert (for you MBTI-ers, I'm an INFJ) so this is well outside of my comfort zone.  I have to make a focused, dedicated effort to be successful at this.

I started down the path of making a focused, dedicated effort by creating a list of questions that I can use to get the conversation started and try to develop an ongoing relationship with these "outliers."  These are probably not the most insightful questions you've ever seen, but they were not intended to be brilliant.  The intention is simply to get the conversation started and find some way to build a relationship.  As the conversation develops and the relationship grows, we'll find common ground for more in-depth interaction.  Note also that I don't plan to ask every question every time I talk to someone.  I might only need one to get the ball rolling.  And I'll need to use my own judgement to determine which questions are best suited to the particular person's situation.

You can read my initial list of conversation starter questions and download them to help create your own list if you like.  What other questions might you add to the list?  What other methods have you used to build connections to team members or stakeholders who are not regular parts of your project?

PMI published a book back in October entitled Project Management Circa 2025.  According to their earlier press release, the book:

brings together 41 project management experts to envision and describe the practice of project management across regions and industries, in the year 2025. The book ... is the first of its kind to discuss what future changes can be expected in the use of project management, and how organizations around the world might be impacted by these changes. 

They also created a Facebook page to stimulate community and discussion around the book and the topic in general.  The page contains interviews, videos, and comments, all of which got me thinking, how do I see project management in 2025?  (Just so you know, I haven't read the book yet.)

I believe, in general, much will remain the same.  Project management as a profession will grow and even flourish as more and more businesses of all types and sizes around the world recognize the value in managing outcomes to benefit their business and improve their bottom lines.  Many processes will continue to be required as projects cannot be managed well without them.  These include communication management, risk management, schedule management, cost management, and human resource management, among others.

However, I see four trends right now that will have a significant impact on project management in 2025. 

1.  Web 2.0.

Web 2.0 includes tools such as blogging, Twitter, Facebook, and so many others.  Social bookmarking, web based tools with integrated social communities, the list seems endless (actually, Go2Web20.net lists 3,094 different web 2.0 tools and applications).

According to Wikipedia (an early Web 2.0 tool itself):

The term "Web 2.0" (2004–present) is commonly associated with web applications that facilitate interactive information sharing, interoperability, user-centered design and collaboration on the World Wide Web.  Examples of Web 2.0 include web-based communities, hosted services, web applications, social-networking sites, video-sharing sites, wikis, blogs, mashups and folksonomies.  A Web 2.0 site allows its users to interact with other users or to change website content, in contrast to non-interactive websites where users are limited to the passive viewing of information that is provided to them.

These tools will bring a significantly greater level of interaction among the project manager, team members, and other stakeholders.  Conceivably, their use could improve the recognition of stakeholders by exposing projects to a larger audience.  But the biggest impact will be on communication.  More people, from end users to non-team member experts, will know more about what's happening and how it impacts them.  The tools will make it easier for them to provide input and easier for the project manager to provide feedback, open discussions, set up face-to-face meetings, etc.  The tools we utilize to manage our schedule, resources, budget, and risk, as well as the sources of information we use to generate and manage these entities, will be impacted by Web 2.0.

2.  Individual Contributors.

By this I mean I expect to see a rise in the power and influence of many individual, independent contributors instead of a few "experts" or the corporate employee.

Solo consultants and freelance or contract PMs have been around for some time and that population and their impact will continue to grow.  As more and more companies employ project management as a practice and the number of projects managed remotely continues to grow, the number of "non-employee" PMs will rise along with it.

I think also, as a direct result of the socialization of the web, companies will rely less on employee PMs and more on the person who can do the job.  Personal branding will have an impact here as PMs with established presence will be the ones turned to first.  PMs who have an established reputation as an excellent project manager, with certification, with experience, who can handle remote/virtual teams, who have demonstrated communications expertise, will be more visible and have first shot at available PM gigs.

3.  Education.

Over the past 15 years, project management has truly come into its own with most companies performing project management is some form or fashion.  It's grown from something only the big government contracts require to something even the smallest effort can derive benefit from.  Now we see hundreds of training programs and university certification, bachelor of science, and masters degree programs.  As the PM profession grows, the need for education will grow.  I know some PMI chapters sponsor high school project management educational programs, and I believe I've read about schools that include project management training in their high school curriculums.  I expect this trend to continue.  In 15 years I think high school level project management educational programs will be commonplace.

4.  Public Visibility.

I like to get a little pat on the head once in awhile, you know, like a puppy who learns to go outside instead of on the carpet.  "Good job, boy!  Keep it up."  When a project is pulled off well, everything works, it's on time and the company saves money, the customer is happy and the users are not complaining, the public recognition goes right to the most appropriate person...the CEO!  Okay, maybe not the most appropriate person but probably the most visible.  I know, that's a major part of what the big honcho is paid for, to be the public face of the company.  And yes, I understand that the upper level manager always gets credit for the accomplishments of the less-upper level people on the team.

But still, wouldn't it be great to see regular business magazine articles that spotlight the project manager who was able to bring everyone together to get the thing done?  I think that internally businesses recognize that a PM was critical to a successful project, but otherwise we rarely hear about PMs who do a great job.  PMI and many PMI chapters do a good job of recognizing successful projects as well as their managers and teams.  There might be other organizations who also recognize PMs.  I think in the future PM recognition will become more visible.

-------

I'm sure other people see other trends affecting project management circa 2025, and who knows if any of them will be right.  Robert Burns said, "There is no such uncertainty as a sure thing."  Let me know what you think about these trends I've identified or what you see for the future of project management.

Performance Review

I don't usually think of my performance review as an opportunity for improvement.  I usually think of it as an obligation that must be fulfilled as a condition of my continued employment.  I'm not planning to debate the merits of employee performance appraisals or the possible lack thereof.  My point is that by knowing mine was coming up and receiving the tweet at the same time produced something not unlike nuclear fusion (OK, it's totally unlike nuclear fusion but just go with me here).  These two nuclei joined in my mind to produce a brand new idea, something with the potential to change every aspect of my work performance and (as good nuclear fusion should) the energy to follow through on it.

Self-Assessment

I started writing about this in my previous post, "Walking on Water?  Or Dog-Paddling?"  The one thing I found that could improve every aspect of my job performance was to take an honest, objective look at how I was performing my duties as a project manager and ask the bottom line question:  Am I adding value?  My honest, objective conclusion was that I did the job in 2009, but it was little more than going through the motions.  I felt like I coasted by doing what was necessary and sufficient but not going above and beyond.  The rest of this article will describe my thoughts and the process I used to perform this self-assessment.  Some of this might seem random, which it was since I didn't have process in mind or a template to follow, but it worked for me.  Remember, the only difficult thing about this exercise is being objective which is tough when you lived through it all.

1.  Write down thoughts on how I did my job in 2009. 

This is how I started my self- assessment.  The idea I had when I started was that no one else would read it.  I was planning to use it as a self help thing and as a prompt for ideas when I was talking to my manager during my year-end review. 

I naturally (some might say obsessively) use correct punctuation and grammar and all that in my writing.  While some might just write bullet statements or a simple phrase to indicate what they're thinking, I write in complete sentences and paragraphs.  As I wrote, the overall format started to take shape.  I also tend to edit while I write so I started moving sentences around and eventually I ended up with an Introduction, Summary, and Foundational Questions.

Introduction:  A lot can happen in a couple weeks or a month or however long I might take between future readings of my self-assessment.  Basically, I thought this would be a good way to remind myself later what I was setting out to do with this self-assessment.  I also included my corporate PM "rank" (level 5 out of 6) to emphasize that I should be doing a very good job.  I should be adding value all over the place, going outside the box to find solutions or improvements, etc.

Summary:  This is where I ended up putting my basic thoughts on how I performed.  I included my overall evaluation (not good) and then some specific thoughts on why I didn't feel I performed as well as I could.  I highlighted my most significant weaknesses of the past year and some of my strengths.  I personally didn't think the strengths were as important as the weaknesses.  Some people might want the affirmation, but honestly, I can always find something I do well.  I tend to skim over or ignore places that I don't do as well so identifying those weaknesses and implementing ways to make them stronger was a key for me.

Foundational Questions:  As I wrote, I found myself asking questions of myself about the direction I wanted my career to go, did it even matter to me, or did I even want to continue in project management at all.  These questions got right to the foundations of my chosen profession so I wanted to leave them in the assessment.  I didn't spend time writing down answers to these foundational questions since, in the end, the answers were very clear to me, but I didn't want to lose track of them either.  I wanted to be able to return to them in the future.

2.  Identify the things I thought I did well (strengths) or poorly (weaknesses).  

The format of this part of the assessment changed the most over time.  I started out simply listing my strengths and weaknesses in columns, similar to a type of SWOT analysis.  As I thought about each trait, I started writing explanations about why I had chosen that particular trait and the list grew. 

Then I wondered, how do I know I considered every trait that would contribute to being a good project manager?  This is the heart of my self-assessment because, as I said, I wanted to give myself the opportunity to improve every part of my job performance.  Of course I could search the web or all the PM blogs I know and come up with a list of PM traits.  Fortunately I had asked a question on LinkedIn about a year ago:  "What traits make up the perfect PM?"  I thought I would get some kind of consensus, but I was wrong.  I got 11 responses, each listing a number of traits.  I put all the traits in a spreadsheet to keep track.  In the end, only a handful of the traits were duplicated in more than one response.  The list in my self-assessment is that list of answers from my LinkedIn question. 

If you decide to perform your own self-assessment using this model, you can update the list to include the traits you feel are important to good project management.

I decided to categorize the traits in one of four ways.  Strength and Weakness are pretty obvious.  I categorized a trait as Both if I could see where I had done it well and instances where I could have done better.  And if I felt I was OK with a particular trait I marked it Neither.  In other words I didn't recognize it as something that made me special or something that needed focused effort to improve.

3.  Figure out ways to improve on my weaknesses.  

This would be my Improvement Plan or goals.  I think this is the most important part of the assessment, though I couldn't have done this part without the preceding parts.  The key value add of this whole exercise is that I come out of it with clear, specific ways to improve my job performance.

Again, this isn't a particularly difficult thing to do.  I just took the weaknesses I had identified and asked myself, for each one, what can I do to address that problem? 

Some of the answers I came up with have specific, measureable tasks that I can perform.  I can look at these at specific points in time and determine if I'm doing them and how well. 

Some of the other answers are just reminders to follow the company's PM processes better.

Some of the answers apply to more than one weakness so I didn't duplicate them.  I just wrote "See xxxxx" to tell me where the improvement step was for that weakness.

Overall I'm happy with these improvement goals/steps.  For the daily, weekly, monthly recurring items, I already have them on my calendar so reminders pop up.  No guarantee that I won't just ignore the reminder, but I do find that the reminders are helpful.

Whether this is something unique that I've done or if I've just been blind to this little self-help activity all these years, I found some value in it, and I hope you found some in this article.  If you want to try this for yourself, here's a template you can use to help you get started.  Feel free to download and modify it to fit your needs.  I'd love to hear if you perform some type of self-assessment even if you don't use this format.  Does the process add value to you?  Does it help you perform your PM job better?

So what happened yesterday?  Actually it was about 2-3 weeks ago I read an article written by Jodi Glickman Brown on the Harvard Business Review blog, The Conversation.  (I also found it later on her blog.)  The article, "How to Sail Through Your Tough Performance Review," really struck a chord with me because I had always considered job performance reviews as an obligation rather than an opportunity.  Usually the process went like this for me:

• I write my review
• I send it to my manager
• My manager changes "walks on water" to "dog paddles just to stay afloat"
• We both review it, and we're done.

At my mid-year review, however, I got some less than positive feedback, and I wasn't exactly elloquent in defending myself.  Now I knew my 2009 end-of-year review was coming up.  I knew it wasn't going to be the greatest review I ever had but didn't know what I could do about it.  Until I read Jodi's article that is.  Here's what she wrote that hit me:

The goal of the performance review, from your perspective (not just your manager’s), should be to:

1. Highlight what you’ve done well
2. Acknowledge areas of weakness
3. Demonstrate what you’re doing now to make things better next year

In my head I was thinking, "She's saying I shouldn't just sit there and take it.  I have some input into this evaluation and I need to be ready to speak up."  To me this was almost a revelation.  It was one of those Ah-ha moments where you can clearly see a solution or where an idea forms practically fully developed into your mind.  I e-mailed the article to myself at work and set up a task with a reminder in Outlook to remind myself to complete my own self-evaluation before the end of the traditionally slow holiday period.

Over the next couple of weeks I did some thinking.  And took some time off.  And thought some more about the eval.  Then I went to some parties.  Saw Avatar (cool movie by the way, I just watched the trailer again, I might take some time this week to go see it again).  And ignored the reminders that popped up on my laptop.  And just like that the holiday slow down was over.  It was Jan 4 and everyone was back at work.  Fortunately for me everyone else did as much as I did over the holidays and used that Monday to get back up to speed and I had plenty of time to focus on a serious self-assessment of my job performance.

I'm not happy about it.  Not satisfied with my performance, I should say.  I'm happy with my self-assessment process and the fact that I actually did it.  I set some ground rules for myself going into it.

1. Full transparency.  Leave no stone unturned and be completely honest.  This was my assessment and I would be the one using it to improve myself, to add value to my performance (so to speak) so I could add value to my projects and for my customers.  Any reservations on my part would limit the value of the exercise.
2. Just write it down.  I didn't want to worry about format.  I was afraid this would constipate my thinking and sidetrack me.  Believe me, it often does.  I think to the point of distraction about where to put commas and whether to use "let" or "allow."  Crazy, I know, but I've learned to live with it. 
3. Leave no doubt.  When I was done, I didn't want there to be any doubt about how I felt about my performance in 2009.  If someone read the assessment, they should not be wondering if I was satisfied with my performance.  Good or bad, leave no doubt.

And that was it.  I started writing and caught myself breaking all three rules.  I often had to ask myself, "What or who am I hiding from?  This is about my performance.  I was there when it happened.  Remember?"  And I had so many ideas about format and word choice and punctuation that the thing took probably an hour longer than it should have.  But in the end I'm happy with my output and feel like I can use it to fend off hold an honest discussion with my manager about my job performance.

And a bonus!  As I was working on my self-assessment, I wondered if other people struggle with this kind of thing.  Do you have any difficulty or concerns or fears about your year-end evaluation?  Have you ever spent honest, devoted time seriously considering how you're doing your job?  Have you ever documented your job performance from a completely objective standpoint and used those results to add more value to your job performance?  If you haven't, or if you're just interested to see how this thing turned out for me, look for my next posting before the end of this week.  I'll write more about the process I went through, talk - briefly, I promise - about my formatting choices, and just overall what I did to create the document.  And lastly, I'll post the finished product revealing all my blemishes...the job performance blemishes at least.  Please let me know what you think about all this in the comments.  Talk to you again soon!

Actual 2009 Christmas Letter

I tried to get out of writing the family Christmas letter again this year.  The entire conversation went kind of like this:

Wife: Have you written the Christmas letter yet?

Me: No.

Wife: (no response, just "the look")

Me: (sat down to write the letter)

After 27 years of marriage that's all that needed to be said.  (Some of you are saying, "Come on, Brian.  You could have figured that out after 27 days of marriage!")  In previous years, there have been discussions of "should we write a letter" or "why write a letter" or "there's really nothing to write about this year" or "don't you dare write a letter like the ______ family's letter" or "why don't you write the letter" and many others.  Now it's just, "Write the letter."

In all truthfullness, I dread writing the letter.  My memory is horrible so I can't recall what interesting thing happened back in January.  My wife on the other hand remembers her every thought, word, action, and emotion for the past...well, all her life it seems.  She even remembers most of mine and our kids' thoughts, words, actions, and emotions.  Don't ask me how.

Plus I have to invent ways to make the letter interesting.  Many people despise receiving these holiday ramblings so I usually try to come up with some running gag or funny misdirection to keep the readers wanting to read it or maybe surprise them at the end somehow like The Sixth Sense.

But in the end, I returned to the reason we (my family) write that letter every year.  We can't see, and sometimes fall out of touch, with people we like and even people we love.  The letter is a way to maintain a connection, let them know what we've been up to since they probably have some existing level of interest, and maybe even renew a more consistent connection with these folks.

Stakeholder Communications

It's really part of the communication plan for the project that is our life.  We have plenty of stakeholders who are up to date on everything that happens in our lives, often because they're right there living it with us.  Close friends, immediate family.  They all get immediate status reports and hear all the details of what's happening.

We also have plenty of stakeholders who only get occasional updates from us.  Maybe we see them at church or the kids' school functions or go out to dinner with them once in awhile.  They get less frequent updates and just the details that are most pertinent to the relationship we have established with them.  They also get whatever information is necessary to fill them in on the background of a particular communication.

But some of the people who get our letter don't fall into either of those categories.  They want to know, they want to keep up, they want some level of involvement, but it's not critical.  If we didn't send them the letter, most of them would probably contact us or find a way to get the information they're interested in.  It could be watered down by then, innacurate, or even slanted in a negative way, so it's good for us to keep them in the loop in our own way.  It's good to make sure they get a true and accurate depiction of our "project."

Personal Note to My Readers

I want to thank everyone who has read or subscribed to my blog this year.  I hope I've provided some perspective or information that has been helpful or interesting to you.

I hope each of you has a blessed holiday season and this Christmas is your favorite one of all.

Please say a special prayer tonight for those who have to be away from family or friends over the holidays whether it's business, an illness, or even a war that's the reason.

Server refresh for online document sharing/management system.  17 physical servers need to be replaced with new ones and 3 virtual servers need to be implemented.

Customer: 

Internal organization responsible for operation of the system

Status: 

I was assigned as PM on this project at what seemed like the beginnning.  Nothing was documented yet -- no scope, no charter, nothing like that.  The customer knew what they wanted to do as a result of discussions with the application vendor, the age of the old servers, and the performance of the old system.  Although the customer had planned to complete the server refresh themselves, they realized they didn't have the time to devote to the effort so they decided to bring in a PM from outside their organization whose only role would be management of the project.

Action: 

After discussing the status with the customer, I set about identifying the other team member roles I would need to fill.  One of those roles would be a system administrator to build our servers and put them into operation.  The customer already had a sys admin on his "payroll."  This admin worked with the customer daily and funding was already allocated to his department to cover his labor expenses.  OK, I thought, one resource identified.  That makes things easier.  I continued to build the small team, began holding meetings, building a schedule, documenting requirements and design, and the project started moving forward.

While creating the schedule I spoke to the system administrator to get estimates on how long it would take him to do the work.  He also notified me that he'd be on vacation for four weeks over the holidays so I scheduled around that.  The customer coordinated on project-related matters throughout the week.  The project was proceeding in an acceptable manner.  Last week I called the sys admin to find out if we might be able to find anther admin to fill in for him while he was on vacation. 

"Well," says he, "it's normally Juan, but Juan will be on vacation so maybe Mary or Tom can fill in but they have a lot of other work to do so I don't know if we have anyone who can fill in."  A warning siren was beginning to warm up in my head.

"Well," says I, "who's your manager?  I'll ask him/her who your replacement will be during your vacation.  That's why managers get paid the big bucks."  He gave me the name and I dropped the manager a line in an e-mail.

The response I expected was either "I have a replacement and here's their name" or "I don't have a replacement so you'll have to wait."  What I got was, "Refreshing servers is completely outside our statement of work.  We do application support and in no way can server refresh be construed as application support."

Wow.  This project had been going on for weeks and weeks and I had spoken with the system administrator and customer on numerous occasions and there was never any hint that my team member was not supposed to be doing the work he was on the team to do.  This was completely unexpected!  If this turned out to be true, I was going from a short delay as the new sys admin got up to speed, to a 4 week delay if we can't find a temporary replacement, to a potential 60-day delay if we have to develop a new statement of work, route it through our corporate bureaucracy, and get a response from our internal provider.

Today I'm still waiting for a ruling on this issue to find out my next steps.  If the server refresh is considered part of the sys admin's statement of work, I need to find a replacement or wait until the guy returns from vacation.  If it's not part of their statement of work, I need to start processing that paperwork to make it part of their statement of work.

What Could Have Prevented This?

Option 1:  Take the time to verify the team member's availability and role.  This could take the form of a more in-depth discussion with the team member.  In this case, the system administrator was already performing server support tasks and did not understand that server refresh was not part of his job.  Talking to him more would not have uncovered this issue.  And if I take the time to verify the availability and role of every team member on every project by talking to their managers, I'll never get anything done.  I don't think there's a good or easy way to determine which specific team members I should verify before proceeding with a project.

Option 2:  Develop a template that describes the work each team member is expected to accomplish, where the funding for their labor will come from, when the work is expected, etc.  Most of this just isn't known at the time the team is being put together.  The PM has to rely on the team members themselves to identify a lot of this.  Maybe this could be a "living document" with basic info when the project starts but more completely filled in as the project progresses.

Option 3:  I don't know what option 3 might be.  I'm open to any ideas! 

To me this situation is a result of the administrator not understanding his own responsibilities and the responsibility for that education goes back to his manager.  It all makes me wonder about this one critical resource:  If this project had taken place at a time when the admin wasn't going on vacation, would this issue have come up?  Would the admin have proceeded with the server builds?  I suspect he would have and nothing would have been said.