Random Acts of IT Project Management

Project Management for Information Technology

Archive for the ‘People Management’ Category

Management By Walking Around By Any Other Name…

Posted by iammarchhare on 24 July 2009

I have posted before about “’Hands On’ Project Management”.  This fits in real well with this topic.

Jon Emmons of Life After Coffee shared his thoughts on “Management By Walking Around”.  Basically, Management By Walking Around (MBWA) is a technique for managing people by going around, observing, chatting, etc.

What it really means to me is that you cannot manage by sitting around in your office.  You have to get your butt out of the chair occasionally and go see what is going on.  It can be tempting to just sit in the chair and shoot off the occasional email and call it “managing”, but that just isn’t particularly effective.  Get up, breathe the air, see the sights and make yourself available to your team!

One caveat: Don’t run around micromanaging everything.  If you are using this time to run around with a checklist asking, "Are you done yet?  Are you done yet?" then it will be counterproductive.  Save that for the status meetings.  The purpose of this tour is different.

The question, though, is what do you do if the team is remote?  If you can visit them, you should.  Obviously, distance will make the intervals longer, but face-to-face time can be crucial.

What you cannot do with face-to-face, you try to make up for by regular telephone conversations, video conferencing and other means of communications.

Yet, as I try to step back and view what it all really means, I realize what we are talking about in essence is something that just plain is lost on most businesses today: relationships.  People are socially geared, and they need relationships.  By constantly communicating, observing, etc, you are building a relationship.  Hopefully, you are building one of mutual respect and trust.


Posted in Leadership, People Management | Tagged: , , , , , , , , | 1 Comment »

Avoiding Project Estimating Mistakes and Constructive Pessimism

Posted by iammarchhare on 10 July 2009

It happens to everyone sooner or later.  Someone made an error in giving an estimate on a task or set of tasks.  The causes can be many.  Sometimes, the estimate might be fatal to the timeline of the project.  How can this be avoided?

Erik Eckel of TechRepublic says that his “Three tips for avoiding project estimating mistakes” are: 1. Confirm all assumptions, 2. Don’t expect trouble-free projects (aka plan for “unknown unknowns”) and 3. Specify exactly what estimates include (aka put it all in writing).  He goes into each of these in his article.

The Defensive Mentality

I’ve been an advocate for “defensive programming” for years now.  Developers are notorious for being overly optimistic.  They can’t fail.  After all, it is their code, and their code always works, right?  I know this attitude to be true.  I was a software engineer myself for a while.  Needless to say, my code did not always work right the first time.  I had to learn to expect that something will go wrong and plan for it.  Just like the driver learns defensive driving and plans ahead because accidents even to good drivers, the developer must plan for strange inputs and react accordingly.  The developer needs to come up with a test plan before coding.  The assumptions should be stated not only in design documents but also as code comments first.

I know what you are thinking, as I have thought it myself: That is going to add a lot of overhead to the project.  The plain and simple truth is that it reduces effort on the project.  Sure, your estimates will go up.  Sure, management is going to question why a module takes so long to code.  The answer is that it actually reduces coding time and, better yet, wasteful time produced by context switching, because there is less rework!  It puts the effort closer to the front of the project, where it is cheaper.  Have you looked to see how much rework occurs on projects?  How much of this was even planned?  Wouldn’t you like to reduce it, planned or not?

The project manager needs to be aware of this and prod people to adopt a defensive mentality.  Basically, when you look at Eckel’s three points, they boil down to being “constructively pessimistic”.  In other words, you expect bad things to happen and plan accordingly.  Even if you use defensive techniques, the PM needs to be pessimistic too and build in rework for a project.  To reword Eckel’s list slightly, the PM needs to challenge assumptions (pessimism that assumptions, particularly about inputs and outputs, reflect reality), not expect lack of problems (general pessimism that all will go as planned without any unit testing and without any rework) and be specific in communication (pessimism about understanding and being clearly understood).

No Fear

Eckel actually has a 4th tip, though.  Near the end of his article, he states, “Analysis paralysis isn’t just for politicians and leaders in other industries — it affects IT managers as well.”  Fear, in his view, makes you less efficient.  As we discussed yesterday in “Keys to Successful IT Projects”, this fear can lead to not making important decisions that would otherwise make the project successful.

So, while I advocate a certain amount of pessimism, don’t make the mistake of rooting the pessimism in grid-locking fear.  Constructive pessimism, however, simply acknowledges that things will likely go wrong and forces you to make a plan for the event.

Of course, you should plan for success as well.  After all, if you are being constructively pessimistic about your constructive pessimism, you’ll also realize that some things go right, so you need to plan for those events as well!

OK, I’m teasing, but only slightly.  Each event will either be a success or not.  What do you do if A goes according to plan?  What do you do if A does not go according to plan?  Always have a back-pocket plan if something of significance doesn’t work out.

Reality Check

Developers are notorious for being overly optimistic.  I have found that many infrastructure engineers are just as optimistic.  They don’t plan for failure, so they don’t know what to do when it hits them.  Many PMs have come up from the technical rank.  Unfortunately, these PMs sometimes still carry much of the same optimism they had before.

“Constructive pessimism” is the antidote to naive optimism.  Naive optimism doesn’t plan for things to go wrong at all.  Constructive pessimism says things will go wrong, but here is what we will do about it.  It provides a reality check to the team.

The funny thing is that this actually increases confidence in the overall project because contingencies have been identified that provide a safety net for the team.

Posted in Estimating, People Management, PM Basics | Tagged: , , , , , , , , , | Comments Off on Avoiding Project Estimating Mistakes and Constructive Pessimism

Keys to Successful IT Projects

Posted by iammarchhare on 9 July 2009

On 26 March 2009, TechRepublic’s Patrick Gray wrote “Five keys to successful IT projects”.  Most of these keys involve methods for grounding the project to the business side of things.

For example, under the heading “IT projects don’t exist in a vacuum”, Gray talks about how “most IT projects are awash in details.”  By keeping business objectives the main focus, however, it makes it much more likely that people will guide the project to the desired conclusion.

The section I really liked was “Decide already!”  Yesterday, I pointed out in “Seth Godin and One Thing” that you need to be able to identify the one or two things that are key to a project.  Fewer than that, and you will stagnate.  More than that, and you will run yourself and your team ragged.  The answer is to set priorities.

Of course, that means that decisions have to be made.  I’m sure that I’m not alone in that I’ve sat in meetings where no one was willing to make a decision.  The person “in charge” was too lame to either state what was really important to enable the team to actually set some priorities or too timid to champion a particular set of projects over another set and rally people to their view.  It’s the type of meeting where you contemplate whether or not slitting your wrists would be a better form of entertainment.

Gray wrote:

Nothing saps energy from a project like a drawn out decision-making process. When fifteen layers of management must be consulted, countless meetings held and a bevy of naysayers brought in whose only function is to quip why “that will never work,” you are destined to failure. Before starting a project, define how critical decisions will be resolved, who has decision-making authority and what the timeframe is for critical decisions. It is better to make an imperfect decision that moves the project forward today than to spend months vacillating and pontificating while time and money fly out the door.

I particularly like the idea that part of managing a project is to manage how decisions are made.  Often, the tendency of a PM is to view major decisions as “out there”.  The view can be that a decision must be made by “the customer”, “the sponsor”, “the CIO” or someone else outside of the core engineering team.  In all honesty, though, even if that is true, these people are stakeholders and really are not separate from the extended team.  It should be part of the change management process to determine who makes what types of decisions.

Of course, a PM must be flexible enough to provide some prodding of the process as well.  There will be times when you will just have to offer up a recommended solution and make them knock it down or approve it.  At best, the recommendation will be approved and the project can move forward.  At worst, you’ll end up with one less choice to make.  Therefore, even if they don’t like the recommendation, you’ll be one step further along.  Hopefully, by telling you why they aren’t approving the recommendation, they will provide enough insight into what they really want to come up with a better one.

In my experience, not being able to make a decision is at the root cause of most analysis paralysis.  More often than not, fear is a factor in this, and that is one of the items we’ll look at tomorrow.

Posted in Leadership, People Management, PM Basics | Tagged: , , , , , , , , , | 1 Comment »

“Project Focused Hours” Per Week?

Posted by iammarchhare on 10 June 2009

Most places I’ve worked have had 75% – 80% of a developer’s time for projects.  80% of a developer’s or engineer’s time was actually quite reasonable at one large company I was at.  However, one place I worked had so many meetings that it seemed I was lucky to get 60%!

Steve McConnell writes on his Software Best Practices blog 10x Software Development in an article “Industry Benchmarks About Hours Worked Per Week”:

Based on what we see in our consulting practice, I think it’s rare to average 6 hours per day of truly project-focused work in a non-startup company. The most common distraction from project-focused work we see is time spent supporting prior releases that are in production.

You know, that to me just indicates either they are releasing bad software or just aren’t planning in enough transition time.  The last place I worked had a “warranty” phase that the project went into once deployment occurred.  It was often 2 weeks long, and time was allocated for developers, DBAs and anyone else that might matter.  That would take care of the last problem.

How do you fix the first problem?  What if the software is just crap?  Well, you have to answer “Why is it crap?”  The answer is likely to be one of the following:

1. You inherited crap.  Crap in, crap out.  The only ways out are replacement or remediation.  If this truly is your problem, it is time to bargain with the ones who hold the purse strings to let you loose on it.  If you truly have inherited crap, it should be easy to show it is crap and it should be easy to show an ROI.

2. Your staff is undertrained in some areas.  I think the solution is obvious.  Again, you probably can show an ROI for this one.  If nothing else, you should be able to show how much you are spending in extended warranty above and beyond normal.

3. Someone on your team would be happier doing something besides programming.  If you are the resource manager, then it is your job to identify these people and make them happier by being somewhere else.  I’m not trying to be mean, but the fact is that they will never achieve greatness, they will always have lousy job performance reviews, they (hopefully) won’t get promoted and if they stay no one, not even they, will be happy.

If you are a project manager, you may have to tactfully bring some of these things to light.  Pound on the ROI, though.

If you are a resource manager, then hopefully you are aware of this before the project manager says something.

Posted in People Management | Tagged: , , , , , | Comments Off on “Project Focused Hours” Per Week?

How To Manage Software Development

Posted by iammarchhare on 9 June 2009

Sometimes, project managers wear 2 hats.  Hopefully, you don’t wear much more than that, or you quickly become ineffective at one of the items.  I’ve done both resource and project management, so I’ve published an article on Helium on “How to manage software development”.  Below is an excerpt from the article:

Management of any team is exercising a certain amount of control over resources: Time, personnel, equipment and processes. However, an effective manager also realizes where management of their particular team is unique. Software development is no exception. While there may be environmental factors that require unique strategies in any given organization, there are general items to be aware of across the board for managing a software development team. You need to ensure that the proper tools, proper environments and proper training are in place in order to ensure successful completion of development projects.

You can read more here.

Posted in People Management, Software | Tagged: , , , , , | Comments Off on How To Manage Software Development

Bridging the Gap

Posted by iammarchhare on 29 May 2009

This week, we’ve looked at use cases vs user stories, basic abilities for PMs and BA competencies for gathering requirements.  All of these involve in one way or another transforming user requirements into reality.  In “Use Cases and User Stories – Just Degrees of Difference?” we saw that one of the issues with user stories is whether or not the customer has built up “trust” in the process.  I mentioned in “Are You Cut Out to be a Project Manager?” that a PM must be able to bridge people and technology.  And, finally in “Avoiding Project Failure: Gathering Requirements”, we looked at some core competencies for BAs or for PMs filling the role.  All of these involve communication.

I couldn’t help but think of communication when I read “The Role of Agile Advocates” by Lynda Bourne on PMI’s blog.  She writes:

Forget the jargon of “sprints” and “iterations.” Communicate in your stakeholder’s language. As an Agile project is progressing through its cycles, what benefits are being delivered and how can they be measured? What contingencies are in place? What real progress is being made from the business perspective?

You know, this has little to do with Agile.  It is good advice always.

I’m of the opinion that all developers should have to either do helpdesk or desktop support starting out.  Why?  Because there is no better way than experience for a developer to get to know how endusers work, how they think and what they want.  You develop a real empathy for them if you care about your job at all.

I learned something early on because of doing desktop support.  I learned that users just want to get their work done.  They don’t care about bits and bytes, routers, packets, objects, classes or any of the other stuff that IT cares about.  They don’t want to learn a new language to talk to you.  All they care about is that their email, spreadsheet, billing or other program isn’t working.  They want it fixed.  I had to learn their language.

Mind you, this does not mean talking down to them.  Some of the people I dealt with were chemists and engineers.  You want to hear jargon?  They will give you jargon!  Don’t even get me started on day traders!  They are from a completely different country!  No, if you talk down to these people, they could put you in your place rather quickly!

Remember, you are rendering a service.  You might have a degree, and you might make more than a burger flipper, but the reality is you are enabling a person/team/company to be more productive.  To achieve that end, you have to be able to communicate, which means listening as well as talking.  You then have to be able to encode and decode the information between a technical core and the business owner/sponsor/customer.

Without communication, nothing else you do as a project manager will be successful.

Posted in People Management, PM Basics | Tagged: , , , , , , , , , , | Comments Off on Bridging the Gap

Conversation Hacks

Posted by iammarchhare on 14 May 2009

Not quite as savory as the “CNN Article on Thinking on Your Feet”, but LifeHacker also posted an article on the “Top 10 Conversation Hacks”.  Some of these are, well, fake.  The first one listed says “Feign sincerity with eye contact and repetition.”  Not exactly my cup of tea, and it almost was enough to make me stop reading.

One is the exact opposite of the CNN article.  “Use silence to win arguments and nail a negotiation.”  Of course, the situations in the CNN article were quite different.

Ever hear the expression “Don’t tell the customer ‘no’”?  Well, they have that one too with, “Say ‘no’ gently – or say ‘yes, but….’”

My favorite is there.  “Ask questions well.”

All of these have links to other sites.  I followed the one from “Become a human lie detector.” on how to detect BS (language may be NSFW).  I loved this one:

The project will take 5 weeks“. How do you know this? What might go wrong that you haven’t accounted for? Would you bet $10k on this claim? $100k?

~ #53 – How to detect [BS]

Anyhow with 10 hacks and lots of links, I’ll leave you to it.

Posted in People Management, Skills | Tagged: , , , | Comments Off on Conversation Hacks

CNN Article on Thinking on Your Feet

Posted by iammarchhare on 13 May 2009

CNN posted an article on “How to think faster, better on your feet”.  While some of the scenarios described might seem a little contrived, there is always room for improvement in dealing with real life social interactions.  This can range from job interviews to potential date conversations.

The article describes 3 ways to “advance the dialogue”.  Instead of letting the conversation drop or die suddenly, keep it going by:

  1. Use “Yes … and…” to keep moving the conversation forward.
  2. Go with your gut instead of trying to think of the perfect response, break the silence with an instinctive one.
  3. Make others look good.  The example in the article was a bit contrived to me, however I like the idea.  Even the example, though, shows that it is just as important to know why you are there.

Sometimes at work I can get caught up in the work environment and forget the social aspect of it.  It’s nice to see articles like this to ground me a little bit and make me think more about the social interactions on and off the job.

Posted in People Management, Skills | Tagged: , , , , , | 1 Comment »

Don’t Make It Hard!

Posted by iammarchhare on 30 April 2009

It never ceases to amaze me just how complicated people can make things.  Human beings have a remarkable capacity to overcomplicate things.

Let’s take project management.  You plan it.  You do it.  You evaluate how you did.  So, what’s the problem?  Usually, the problem is that people are involved.  You not only have to manage risks and issues, but you have to be aware of the human potential for creating risks and issues independently.

A co-worker manager once remarked that managing software developers is like herding cats.  I cannot take offense at that, as I know I resemble that remark.  Cats are independent and unpredictable.  People are too.  Software engineers are sometimes even more-so.  In an effort to work out all contingencies and to be all things to all people, software developers will sometimes code in things that are too complex for what is needed.

A good PM needs to be mindful of these things and be able to cut through the noise.  Simplify, simplify, simplify.  Even doing a WBS is an exercise in breaking the complex down into simpler more manageable components.

That doesn’t mean that things don’t just plain go wrong.  In fact, I’ve noticed that things go wrong every day.  On a good day, perhaps only one thing will go wrong.

However, how your team reacts to these events can make things better or can make things a lot worse.  This is where the PM must put on their motivational hat and get the responsible party or entire team to focus.

I had a conversation earlier this week that bowled me over.  One of the people was making a big deal out of implementation.  All I could think was, “Why is he making this so hard?” and “Why is he making a big deal about this?”

Things go wrong.  We all know that things can and do go wrong during implementation.  What causes things to go wrong at implementation?  I mean big things; I mean things that go terribly wrong.

  1. Someone wasn’t doing their job.  Unfortunately, this is usually the cause.  Someone overlooked something, had a hidden agenda or otherwise had a “human moment”.  We’ve all done it (well, except hopefully the hidden agenda part).  That “someone” may be a developer, a tester, a manager or even the customer.  Yes, the customer has a job too, and it is your job as the PM to gently remind them of that if they forget, just as you would any other member of the team (including yourself!).
  2. It just plain wasn’t meant to work right, at least the first time.  It might be an act of God, nature or just plain chance.

These are both tricky.  In some environments, even the latter category can be a political nightmare.

When someone fell down on the job or even if they fell asleep at the wheel entirely, it is helpful to remind yourself of all the good the person has done throughout the project.  Go over this list at least 3 times before you have a chat with them.  If you have difficulty thinking of anything substantial they have done right during the project, at least one of you definitely has a more severe problem.

Some things just are going to happen.  Some things may be more predictable than others, and it is prudent to ask if reasonable steps were taken to mitigate such a situation.  It is unlikely you can predict a lightening strike during a rollout.  However, if all that occurred was that the power grid was knocked out, then a reasonable effort would have been to ensure servers are on backup power.  The question remaining would be if a remote PC console would be on a UPS under reasonable circumstances.

One thing about a rollout is that it is the culmination of effort up to that point.  The implementation phase is that is where the entire project will either be deemed a success or failure.  There is very little ground in the middle.  If contingencies have been planned throughout the project, it will likely be a successful implementation.  Otherwise, it could be a nightmare.  The implementation will be a culmination of not only the smaller successes along the way but also a culmination of the smaller failures made along the way.

When things go wrong during implementation, they are either from mistakes made much earlier in the process or they are things over which no one would have reasonably planned.  Implementation issues are rarely exactly that, as even the planning for implementation needs to take place before the actual event.

Posted in People Management, Risk Management | Tagged: , , , , , , , , , , , , | 6 Comments »