This week’s PMS Relief offers a cartoon illustrating a day in the life of a developer, and shows you why can get… distracted.  Enjoy!

http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef013482cd8faa970c-580wi

http://www.microsoft.com/education/competencies/humor.mspx

This in and of itself is not a bad thing.  If you can help reduce stress by taking on a little extra escalation during hard times, you should.  The real danger in this is, as you see more escalations, more “negative” things will be flowing to you.  Worse, the same thing will go on with your peers.  If you manage shared resources in the company, such as in IT or Marketing, your names will show up to more and more of your peers- and pretty soon, if the same people are mentioned in the same discussions as problems, a dark cloud can start to form around otherwise perfectly normal activity.  Somehow, with all the increased escalations and contention, things that are actually running just fine may become painted in a bad light.  Just like surrounding yourself with negative people, getting surrounded by negative news has a bad effect.

The answer in times like this is simple:  get out of your office.  Bad news (or bad news-like information) will be flowing to you, and in increased amounts.  Get out of your office and go talk to people.  Pick your busiest people, your most productive people, your most honest clients.  Do reality checks.  Yes, more escalations are flowing to you, but are things actually going wrong?  Are your clients still getting good service?  Other than more busy, are your people really having problems?  If there’s positive out there, go find it.  As people get more and more busy, the positive won’t flow to you.  People will get things done, then  move on quickly to the next thing.  Track it down.  Make sure things are okay.  Encourage the same in your peers.  Don’t let “busier” get confused with “out of control”.

http://videogoneviral.com/2010/05/spot-the-it-consultant-pic/

Consider this approach for a moment in the light of the concept of technical debt.  Increased features and new products mean more maintenance costs.  Increased speed to market means increased bugs.  Rising technical debt means that your team will be able to contribute even less in the mid-term and long run.  Contributing new, buggy things rather than increasing the value of what you have simply lowers your perceived value to the business.

Before deciding to add new projects, products or features, ask yourself this:  is it time instead to pay down existing technical debt?  What can I do to lower support costs?  How much better can I make what I have?  Do I have any open requests from the business to solve old problems?  Can I increase my perceived value by simply focusing on lowering overhead and getting rid of ‘old’ problems that have been lingering?  Turning your efforts inward to improve now will give you a stronger position in the mid-term and long-term.  You will have lower maintenance later when you ramp up new projects, and by clearing your backlog, you’ll be surprised at how much support you will garner from your business partners.

Today we’re here to talk about the anti-communication.  Assumptions.  We all have them.  We all make them.  And they are slowly killing your projects on a daily basis.

Okay, so maybe it’s not that bad.  Assumptions are , however, a significant, real danger that you have to watch in your project.  They are big enough that this topic should come up on every project risk assessment.  There are five major types of assumptions you have to watch for:

• Assumptions of understood information:  not everyone in your project knows all the terminology or has the same background on what you’re doing.  Not everyone will say so, however.  It’s sometimes difficult to speak up when you feel like the only one in the room who doesn’t know something.  Level the playing field whenever possible here.  Open up conversations in project meetings and make sure you get folks on the same page whenever possible.
• Assumptions of understood responsibilities:  not everyone will automatically know what their tasks are, or when to start them.  Make sure you follow up with folks often.  Seek clarity when you do, and if someone doesn’t understand what they need to be doing be active on getting it fixed.
• Assumption of dedication:  your project will not stay at the top of everyone’s priority list.  It just won’t happen.  Something will come up.  Keep an eye on your resources to be aware of if they are on task.
• Assumption of interest:  not everyone will support or want your project, no matter how good of an idea it sounds like.  There’s always some people who don’t like change.  Keep an eye out for these folks and work with them where you can.
• Assumption of correctness:  Projects always begin with the premise that this project is the right thing to do.  Anywhere, any time during your project, it might be discovered that this is not the case.  I can’t tell you how many times I’ve seen a project continue on long after it’s discovered that folks are on the wrong track.  Keep an eye out for validation that you’re doing the right thing.

These sound like common sense, but common sense sometimes gets left on the side of the road as projects gain steam.  Keep your eye on these things in your projects.

For your PMS (Project Management Syndrome) relief this week, we find a fun little article from Women’s Day Magazine entitled, simply enough, The 7 Stupidest Employee Mistakes Ever.  Sadly, I’ve seen one or two that might’ve been stupider in my time, but these are entertaining nonetheless.

Enjoy!

Overcommunication is a symptom of lack of clarity over power.  If you want better communication, clarify the following:

• Who is the single person who has decision making authority for decision X
• Who should have input into that decision
• Who should be informed when the decision has been made

What Scott’s points address, really, is people’s tendency to defer.  It’s a proven theory that if a person is lying helpless on the street, the more people are present, the fewer are willing to do anything- and so it goes with meetings and projects.  You *have* to do something, it’s your job, so you do- but what people do is the path of least commitment.  They talk about things, rather than make decisions and take action.  The act of clarifying what has to be done and who must do it immediately removes that ambiguity for everyone and gets the team moving.

This leads to how to improve your meetings and projects- always make certain that actions that need to be taken are captured, including decisions to be made.  Make sure that the person responsible for the action is declared.  Doing so is a basic principle in project management, but it often gets lost in the communication aspects.  Calling a meeting to clear a roadblock or make an important decision is not enough; who has authority to solve the problem needs to be decided as well.