Keys to Successful IT Projects

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.

Technorati Tags: it pm,information technology,project management,analysis paralysis,business requirements,objectives,making decisions,decision making,change control,change management

Technical Debt

I always wondered what it was called when bad decisions, bad programming or even the “we need this now” syndrome create a backlog of things that, sooner or later, will have to be fixed.  Well, it turns out that it is called “technical debt”.  Steve McConnell wrote about “Technical Debt” on his 10x Software Development blog.

McConnell distinguishes between the unintentional and the intentional.  Bad programming would be the first type.  The “we need this now” scenario falls under the second.  The willingness to cut corners in order to save the situation today may result in future rework (and, in my experience, almost always does).

Like credit, you will likely have long-term debt and short-term debt.  Also like credit, short-term debt needs to be paid off soon and frequently, while long-term debt might be years away from payoff.

When does it make sense to incur technical debt?  When the cost today is more than the cost in the future.  Often, financial debt is taken on when the rate of inflation creates cheaper dollars tomorrow.  If the interest rate is sufficiently low, then the debt can easily be justified.  McConnell argues that there also are circumstances in which technical debt makes sense.

McConnell’s financial comparisons don’t end there, either.  I think the most important point he makes is to not ignore technical debt and make it visible.  I can relate to this, as I know of one organization that made hiding inconvenient facts into an art form.  It always backfired, but it seemed the individuals involved kept doing it instead of learning from the experience.

I’m not going to regurgitate his entire article, which you can read here.  Since there are times it makes sense to take on technical debt, he also has a follow-up post, “Technical Debt Decision Making”, which is also a worthwhile read.  I really like how McConnell breaks down the costs in the follow-up article.

Technorati Tags: it pm,project management,defect tracking,change control,technical debt,mcconnell,strategy