The Best of IT Project Management

ProjectManager.com © 2013 All Rights Reserved 1

The Best of IT Project Management

A selection of professional insights from the Blog archive


Since 2008 our project management professionals have been sharing knowledge,

experience and learning with online readers via the Project Manager Blog.

Their collective wisdom provides a wealth of how to, top tips and best practice advice,

for project managers, teams and businesses.

To make their writings more accessible we’ve created a series of “Best of” project

management topics available free to download and share.

Here is a collection of excerpts from blog posts that discuss IT project management and

offer some insight on project manager styles, skills and advice for successful software

development.

Enjoy

Jason Westland CEO

ProjectManager.com

Why IT Project Planning Should Always Include Plan B .............................................................................. 4

Does your IT Project Plan Include Setting Up a War Room? ....................................................................... 7

When to Run Away From Your IT Project Management Plan ................................................................... 12

IT Project Plan Completion ........................................................................................................................ 28

IT Project Planning and QA ........................................................................................................................ 30

Apologetic Project Management in IT ....................................................................................................... 33

4 Problems About Doing It All Yourself ..................................................................................................... 36

Keep Arrogance out of IT Project Management ....................................................................................... 39

How to Plan a Software Project that Works ............................................................................................. 40

Removing the Smoke Screen with IT Planning Software .......................................................................... 43

http://www.projectmanager.com/


The Top 10 Project Software Development Mistakes ............................................................................... 46

30 Day Free Software Trial ........................................................................................................................ 50


Why IT Project Planning Should Always Include Plan B

If you’ve been around IT project planning for some time, you will

quickly realize that nothing ever goes as planned. Technology is

complicated. That’s why they call it technology. It’s always moving and

there are new and exciting ways of doing things better and faster.

There is uncharted territory when it comes to pushing the envelope from an IT

perspective. But, this comes with steep learning curves and the possibility of mistakes

that could happen at any time and throw a heretofore well executed plan off kilter

quick.

Plus, technology resources have a tendency to be, let’s say, a little “conservative” in

their estimates for how long something will take. It never fails to amaze me how long

someone thinks something will take when you compare it to how long it actually took.

The numbers can be in the order of 2, 3 or sometimes even 4 times longer (if not more)

than previously expected.

I’m not sure why this is, whether the person providing the estimate always believes that

everything will go without a hitch to maybe just having short-term memories of how

long things actually take.

Regardless, it’s up to you as a project manager during the IT project planning process to

make sure you understand this phenomenon and account for and compensate for

conservative estimates.

Finally, there’s the other “fires” that get in the way of a smooth running project that will

quickly relegate your project to the back-burner to be worked on later.

There may be a big deal that was just signed, and in order to get the engagement

requires that a very aggressive timeline be met. All resources are pulled from current

projects and thrown toward this game-changer of a project.

The trick is that it’s not like the date for your current projects change. It still remains the

same. It’s that it has now ignited into another fire itself!

How Can You Implement Plan B?

Do you include a section in your IT project plan that says “Plan B?” Of course not!

Ideally, you won’t have to implement Plan B. But, in the event that things do go wrong,


Plan B is something you carry around with you in your back pocket to pull out later, if it

becomes apparent you need to buy some time. Here are three ways you can

incorporate a backup plan into the IT project planning system.

1. Add More Time to the Plan

We’re not talking about padding the project plan for the sake of sandbagging and then

bringing in the project earlier than expected. Rather, we are talking about being

extremely realistic and pragmatic about the numbers you are receiving from your

resources. There is no set rule on how long something will take above and beyond the

initial estimates, but you’ll be able to figure that out in your environment based upon

experience.

2. Line Up Additional Resources

Throwing more resources at an activity on the project is called crashing the project plan.

In some cases this works well, in other cases it can go terribly wrong by having too many

cooks in the kitchen. Having to bring everyone up to speed sometimes takes time and

may not be the most beneficial path to take. In the

event that it does work, you want to make sure you

have resources identified up front that, in the event of

getting behind, can be applied to the project and get

things back on track.

3. Negotiate Plan B

This one is a bit tricky when it comes to the IT Project

Planning process. Let’s say you are working with a

Client on a project. You know that it’s running behind.

You also know that if given a bit more time you could

include an additional feature without too much

overhead from your side in addition to the original scope. You offer to the client that

you could do both as long as the time frame was extended a bit. Some clients will jump

all over that offer and others may reject it and say they want the original scope on the

original date. It’s now up to you to figure out how to make that happen with a different

approach to Plan B.

http://www.projectmanager.com/onlineprojectplanning.php

http://www.projectmanager.com/resources/wp-content/uploads/2012/08/a1a129.jpg


Should You Tell Your Project Team About Plan B?

Not necessarily. You’re not being Machiavellian here by not telling your team all that is

going on or that you have something in your back pocket that can be used in the case of

an emergency. Remember, you are working down Plan A…ideally you will never have to

use Plan B. Keep everyone focused on Plan A, have everyone push as hard as they can

for the original plan and remember the best case is to get it done.

Your team members will figure it out eventually that you always have a Plan B in the

case of an emergency. They will also appreciate that you’re doing and have done all you

can to keep chaos and discord out of everyone’s professional life by sticking to Plan A.

Stay one step ahead of your project team and you’ll be a highly valued project manager.

Do You Have a Career Plan B?

By extension, having a Plan B applies to your career as well. I’ve seen too many people

put all of their eggs in one basket and think that nothing could possibly go awry with the

company where they have been employed for many years.

Unfortunately, through no fault of their own, they may find themselves out on the

street because the company went out of business, was bought by or merged with

another company, or layoffs occurred. Have a contingency plan in the event this worst

case scenario comes to fruition with your IT Project Management career. Always have

your resume up to date, take advantage of networking opportunities to meet other

people, and most importantly help others out while you are in the position to do so.

You’ll be glad to be in the position of having a Plan B in the event of a disaster within

your company as you step right over into your next position. You can see the value of

having a Plan B in the IT project planning process. You’ll always be one step ahead of

your project team by anticipating that things may go wrong and planning for them

accordingly.


Does your IT Project Plan Include Setting Up a War Room?

There are a number of different types of

projects and scenarios that will present

themselves to you and your team that would

necessitate having a war room. For example:

Large Deployments

Your team has been working for the past 9

months on a substantial upgrade to the

software product your company maintains. It

has gone through design, build, and testing.

All lights are green and you have now scheduled a date for this application to move into

the production environment. This is a great opportunity to include a war room in your IT

project plan.

It’s important to have all-hands-on deck during such a deployment. Have a

representative there from each department, group, and subgroup that is responsible for

monitoring the progress of the successful deployment. They should be responsible for

monitoring their own team and reporting to the larger group accordingly.

There are many moving pieces that occur during such a large-scale deployment and the

opportunity for something to go wrong is right around every corner. There’s no time to

pontificate about who is right or wrong during such times, but rather, focus on what

needs to be done to get the situation fixed and back on track.

Anticipation of Something Going Wrong

A second scenario where it is good to include the idea of a war room in your IT project

management is when there is a high likelihood that something will go wrong. Simple

project risk management, let’s say you work for a retailer that sells a number of

products online. You know the Holiday season is coming and traffic is going to start

picking up. Couple this with the fact that you know there are heavy discounts and free

shipping associated with this event and you have the recipe for a disaster.

This is another good opportunity to get the right people to huddle together in a strategic

location to make sure that everything goes as smooth as possible. There are people

monitoring hardware, site visits, bandwidth, latency and other key metrics and

http://www.projectmanager.com/itprojectmanagementsoftware.php




components related to keeping the site up and running during this potentially hazardous

time.

When Something Has Gone Wrong

This is the least desirable of the three scenarios that you would need to include a war

room (or the potential for one) in your IT project plan. This is when something has

actually gone wrong. A risk has been realized and turned into big-time issue. Your

production environment may be down and nobody has any idea of why!

This is when you pull this group of leaders

together and nobody leaves until the issue is

fixed. There is no higher priority that anyone

should be working on other than fixing what

has gone wrong.

How a War Room Should Be Set Up

There is no particular formula to how a war room should be set up if you include this in

your IT project plan steps, but there are a number of principles, when documenting a

project plan, to ensure a war room is effective.

1. Location

If at all possible, it’s best if the core group of stakeholders on the project meet face-to-

face. This may not be possible at all times due to disbursed work teams; however, if it is

possible do everything you can to be at the same place face-to-face. This allows for

better communication, increased focus, and ultimately better results in the end.

2. Conference Call Numbers

While the core team will be at the central location, there

will be other members that are peripheral to the team or

additional stakeholders that will need to know, or want to

know what is going on. Be sure to set up a telephone

bridge and provide them with this information so they can

join at the appropriate times.




3. Contact List

This is something that needs to be done prior to a high-stress situation or crisis. Compile

the name, numbers (not just one, but as many as possible), email address, and any

other way possible that you know how to reach everyone. You don’t know what the

emergency will be and thus you’re not sure who will need to be called in to assist. It may

be an Engineering problem, or something a DBA can assist with, or a business issue that

needs the Client Relationship manager to be available. Keeping this list current and up-

to-date will prevent a lot of angst later when something does go wrong and you can’t

get reach the right person.

4. Criteria for an Emergency

This is also something that needs to be done

ahead of time. What are the criteria for an

emergency? There’s nothing worse than making

a big deal out of something and pulling

everyone together for an issue that really wasn’t

that big of a deal. You will be met with a

collective sigh and “that was it?” from those

who have been unnecessarily dragged out of

bed to assist. The opposite of this holds true as

well. If something really was an emergency and nothing was done about it, this comes

with its own set of problems.

Compile and have everyone agree upon the criteria for what constitutes an emergency.

Then, when a situation arises you can go down this list and make an educated decision

as to how things should progress with your IT project plan.

5. Reporting Structure

This is an important aspect of putting

together an effective war room and including

it in your IT project plan. You need to make

sure there is a clear hierarchy for who makes

the call to assemble the group and runs the

war room while it is operational. This is also




the same person that makes the decision that it is no longer needed and that the

problem has been resolved to the satisfaction of all stakeholders.

6. Communication Plan

A communication plan is important in order to make sure everyone is updated on a

regular and consistent basis. Otherwise, you will end up with people calling in all day

and all night checking on status and interrupting those that are responsible for making

sure things get done or fixed. If everyone knows that a brief communication will be sent

out every hour on the hour or some other frequency, then this will allay some of the

concern and trepidation that other very concerned stakeholders may have.

A war room is not something that needs to be included in every IT project plan.

However, if you work with large deployments or something has gone wrong, this is an

effective tool that can help keep things on track and close the project out.

6 Qualities of IT Project Managers that Suck

The following 6 qualities of IT Project Managers that suck are based upon these two

characters.

1. They’re Hot Heads

They’re on the extreme opposite side of calm, cool, and

collected. They’re a powder keg that can go off at any time

and for any reason. You never know what it is that will set

them off. However, you know that you need to carefully

measure each word you utter in their presence. One day,

things may be perfectly fine with what you stated. The next

day, you may say the exact same thing and KA-BAM! Off they

go!

2. They’re Wafflers

Terrible IT Project Managers are unable to take a position and stick with it. They’ll look

you right in the eye, tell you one thing…and then a day or two later, take a position or

make a statement that’s 180 degrees from what they just told you. This creates an

environment of distrust and audit trails. Oh, and it’s a phenomenal morale breaker, too!

http://www.projectmanager.com/resources/wp-content/uploads/2012/06/hotheads1.jpg


3. They’re Arrogant

Nobody, I mean, NOBODY knows as much as these enlightened IT Project Managers

know. They have extraordinary IQs (in their own mind), can handle any situation single-

handedly, and think that everyone around them is there to

serve them (along with their sub-par mental capacity). They

listen to no-one, never act on anyone else’s suggestions and

believe the world revolves around them.

4. They “Motivate” with Fear and Guilt

IT Project Managers that suck have two tools they use to

manage people – fear and guilt. They have never heard of

teamwork, self-empowerment, accomplishment and all those

other crazy motivators that normal people use to get things done. They keep people in

their place by threatening them with the consequences of what will happen if things

don’t go their way. Or, they try and put a “woe is me” guilt trip on people by telling

them that they’ll have to stay behind to get all the work done, themselves. What they

fail to mention is that this was due to poor IT project management on their part.

5. They Work Stupid Hours

When I say stupid hours, I don’t mean stupid hours

like 60, 70, or 80 hours a week. I mean stupid hours

like Overnight, 3 days straight, sleep on the couch

at the office stupid hours…and then blame

everyone else for why they had to do this.

It’s a lack of discipline more than anything that puts

‘IT Project Managers that suck’ into this bind. They focus on the wrong things all day

long – when the team is right there – and waste everyone’s time. Then, everyone leaves

and they’re left alone, holding the proverbial bag that they need to finish, themselves.

6. They’re Inconsistent

You never know where you stand with these people. One day

they’re your best friend and talking about how well things are

going, how things have really changed, and that they appreciate


http://www.projectmanager.com/resources/wp-content/uploads/2012/06/inconsistent1.jpg


http://www.projectmanager.com/resources/wp-content/uploads/2012/06/arrogant1.jpg


what you’re doing. The next day, they’re running up to the executive suite to throw you

under the bus! I mean… GO FIGURE!

A couple of questions come to mind when you think about IT Project Managers that

really s-u-c-k:

Firstly… how on earth did they even get this position, let alone stay in it? I really don’t

know. From what I’ve seen it has been more a function of WHO they know (they may be

related to someone higher up) than WHAT they know.

Next… what can you do if you’re unfortunate enough to work with someone like this? If

you don’t see an end in sight, I would recommend finding another position, either

within the existing company or elsewhere. There’s no reason to be subjected to this

type of ineptness on a daily basis. If you do see an end in sight, you can grin and bear it

knowing that it’s just a matter of time before things get better.

The reality is that at some point, with enough missed deadlines and complaints,

somebody will say “enough!” and get rid of this person. In the meantime, just make sure

you don’t have any of the qualities above and keep doing your job the best you can!

When to Run Away From Your IT Project Management Plan

If you come across the word “Integration” in your IT project management plan then it

basically means this…you need to align the people, processes, and systems that are

running at 100 MPH in one organization or

department to the people, processes, and

systems that are running at 100 MPH in

another organization or department. This all

needs to be done in real-time without the

slightest hitch or hiccup that would prevent

the business from moving forward.

It can be compared to refueling a plane in mid-

air. Two planes need to align their position and speed perfectly in order to perform this

dangerous maneuver while the hose is coupled between the two planes. That’s the

epitome of an integration project!




IT Project Management Plans that include integration need to include many different

components as well. We mentioned the people, processes, and systems between the

two departments or organizations. More specifically, this means Data, Information,

Workflows, Approvals, Interfaces and a host of other elements that need to be 100% in

sync once the integration project is complete.

Why Would Some Run Away from An Integration Project?

As you can imagine, an IT project management plan that includes integration is fraught

with potential problems and danger for a number of reasons. The following are four

reasons why this type of project is particularly tricky.

1. It’s Hard to Catch Everything – No matter how much planning, no matter how much

preparation and discovery has gone into the IT project management plan, there is

always going to be something that is missed. It may be as small as an IP address not

being updated somewhere in the system to something much larger being missed, such

as a Data Feed that includes key account information not being updated.

2. Major Things are Glossed Over – For the sake of expediency and depending upon

who the source is, major things that should have much more attention given to them

are sometimes glossed over as being minor. The problem is that this thing that everyone

knew to be major did indeed end up being major by the end of the integration project.

Here’s an example of what I mean: Training and Documentation is typically one of those

items that people will dismiss as not being that big of a deal. All too often you’ll hear

things like…”hey, it’s just putting a manual together with a couple of screenshots. How

hard can that be?”

The reality is that this is a very big component of moving people over to a new system or

way of doing things. Everything else could have gone perfectly smooth with the IT

Project Management Plan, but by the time it comes to training and documentation it

falls flat on its face. Why? Because the proper time and resources were not allocated

toward this “minor” activity.

3. Opens Opportunities for “Blame-storming” Sessions – We’ve all heard of

brainstorming sessions where people get into a room and throw out a bunch of ideas

until something finally sticks and then is acted upon.


Because there are so many people involved in an integration project, and they are

usually from different departments, and many times different companies, it opens the

door to the possibility of a blamestorming session. This is where a bunch of people sit in

the same room and throw a bunch of names out for the reason why things went wrong.

Eventually, someone’s name will stick and it ends up being their fault. This gets

everyone else off the hook!

4. It’s Not Easy to Know Where the Problem Lies – During an integration project there

is a 50% chance that the problem is on one side or the other of the proverbial fence.

Despite this fact, the initial reaction from most people on an integration project team

will always be to assume that the problem lies only on the OTHER side of the fence.

There is no way it could be a problem on THEIR side of the fence.

NB: This feeds into #3 above and makes it particularly challenging to navigate through

an IT project management plan successfully.

The above are just four reasons (believe me, there are more) of why project managers,

if given a choice, would most likely steer clear of an integration project. Yet, there are

many success stories of integration projects that have gone very well.

How to Make the Most of an Integration Project

If you are fortunate enough to manage an IT project management plan that includes an

integration component, then take heart. There are some things you can do to make it go

as smooth as possible.

1. Watch Your Attitude – Just know that things are going to take twice as long as

expected. Twice as many things will go wrong, and you will be blamed for twice as many

things that didn’t turn out as expected.

It’s OK. It would and will happen to nearly

anyone that takes up a project that includes an

integration component. Have contingency plans

in place to account for this extra time that is

necessary and don’t take things personally. Rise

above the noise and do what you can to

professionally move things forward.



2. Get Rid of “It’s Not My Fault” Mentality – When something does go wrong, the first

thing you need to determine is what caused the problem. As you go through this

exercise, keep it in mind that there is a 50% likelihood that it could be your fault just as

much as it could be the other guy’s fault. Objectively work through the troubleshooting

process until the issue is isolated. Over time, you will find that you will be indicted about

50% of the time and vindicated the other 50% of the time.

3. Work Collaboratively – When the problem above is identified and it ends up being

“the other guys fault,” work collaboratively to get it fixed. There should be no concept

of “it’s your problem”. Rather, the project should run along the lines of “it’s our problem

until things are resolved.”

The reality is that it IS your problem just as much as it is theirs because it has the

potential of holding up your deliverables as well. Fix things collaboratively.

4. Keep a Detailed Issues Log – Keep a log of issues that are open that includes current

status, next steps, and who owns them. This may seem counter to working

collaboratively, but the opposite is true.

There are going to be executives that want a current status at any moment in time. If

this Issues Log is properly maintained, they may be able to use their influence to help

push through some of those issues that have been plaguing both sides.

There’s no need to run away from an IT project management plan that includes

integration in its scope. However, you should be prepared as a project manager to know

that it’s definitely more of a complicated project.

Will it go perfect from beginning to end? Of course not! Few things rarely do. However,

you can find that by applying the principles above you have the chance of being that

much more successful on your next integration project.


Make Sure Your IT Project Plan is Realistic

There are a number of factors that come into play on whether a resource on your team

is effective or not. You should consider the following questions when determining

whether the estimate someone gave you is based in reality:

What is this Person’s Knowledge and Skill

Set? – You want to ask yourself whether

this person has the aptitude, education, and

training in order to perform this particular

task. If they have gone to school for what

they are working on or attended some

recent training sessions then you can have a

higher level of confidence that what they

come back with is a realistic time frame.

What is This Person’s Prior Experience –In addition to formal education, and

arguably more important, is the person’s level of experience with what they are

estimating. If someone has had 20 + years of experience in a certain field and

working on this particular deliverable, then you can feel very confident that their

estimate is based on reality. You may be a bit more skeptical if this is their first time

up to bat.

Is This Person a Good Multi-Tasker? – Multi-tasking is the scourge of most work

environments these days. It is, however, an unfortunate reality in which we all must

operate. Determining whether a person is a good multi-tasker doesn’t necessarily

come into play if you are looking for a reality check on the duration of the task. For

example, someone may say that a task may take 40 hours of effort. This will be

spread over 2 weeks of time to accomplish. If they are not a good multi-tasker, they

may quickly be pulled off track or take longer than usual to ramp up again to get

things going. You need to know this for your IT project plan because it may actually

take them 3 weeks to accomplish this task rather than the 2 weeks they originally

estimated.

How Motivated is This Person? –You need to know whether this person is driven to

deliver the results in the time frame estimated or whether they just go along with

the flow and just allow things to happen. You can have a higher level of confidence in

the accuracy of the estimate by someone who is driven, focused, and concentrating

on what it takes to get the job done.



The answers to the questions above play into the productivity of a particular team

member on the project. The next area you need to focus on is how efficient a resource

is in order to develop a realist IT project plan.

Measuring Efficiency when Creating Estimates

A common misperception, especially for newer

project managers, is that if someone is

working a 40-hour week then you can bank on

40-hours of time being spent on a particular

project. It doesn’t take long to determine that

there is nothing further from the truth than

that statement. In order to develop a realist IT

project plan you need to factor in the following

distractions when it comes to efficiency:

Non-Project Related Work Activities – You need to understand how much time a

person is being pulled in different directions in their current position .They may be

asked to attend company and departmental meetings, training conferences, or just

keep up to speed with what is going on in the industry. These are all activities that

take time that you need to factor in when it comes to putting a plan together that is

realistic.

Personal Activities – Today’s work environment is no longer the sweat-shop

mentality from generations ago. Knowledge workers today have a lot of freedom and

flexibility to come and go as they please as long as the work is getting done. You

need to account for this time and make adjustments if this freedom and flexibility

begins to be abused. Other things such as breaks, getting work areas organized, or

chatting with co-workers all need to come into consideration when you are

determining how much time to bank on from this particular resource.

General Availability – Most companies today have relatively decent vacation or

personal time off policies. This is another area that must be factored into the time

this person has available to perform their tasks. You can delude yourself into thinking

that they won’t take advantage of this part of their compensation package, but that’s

what you are doing…deluding yourself. Factor this time in when putting your IT

project plan together.



If you keep your eye on the effectiveness and efficiency of your resources and have a

clear understanding about what this means, you’ll find that your project estimates are

grounded in reality.

Is There a Reasonable Utilization Percentage?

Since we like to follow certain rules of thumb as project managers, you may wonder

what would be a reasonable utilization percentage to plug into your plan. Typically, the

more experienced and higher up the seniority chain a resource is, the less time they will

have for direct project related work. Their utilization percentage may fall to as low as

40%-50% with all of the other meetings they need to attend and responsibilities they

have acquired through the years. A newer resource, however, with minimal distractions

can realistically be in the range of 70%-80% utilization.

With a solid plan in place based upon real work-effort numbers, you can now get a true

reality check when you walk down the hall and run into someone on your project team.

This will allow you the opportunity to dig into other details that may need your skills as a

project manager to resolve so the project can move forward!

Things We Hate as an IT Project Manager

Hate is a strong word. We try and teach our kids not to hate and we do everything we

can to keep hate out of our daily lives and relationships with other people. However, in

some instances “hate” does have its place and that’s what this article is about. There are

certain things that I have encountered throughout my career as an IT Project Manager

that I have come to loathe, abhor, detest, and outright hate! If this article comes across

a little cynical or caustic than usual…I apologize. This is welling up from decades of being

on the front line as an IT Project Manager.

With no further ado, here are the Top 10

Things I HATE as an IT Project Manager…

1. That’s Not My Job

Here’s the scenario. Your project is going along

just fine until you run into a bit of a resource

issue. One of the key resources on your project

has been out of the office for a couple of days



due to being sick. The deliverable he is working on is running a bit behind. You know

that this particular deliverable is on the critical path and you need to do something

about it as the IT Project Manager.

You then remember that there’s another resource on the team that used to do the sick

resource’s job. You approach this person and ask if they can help out. Not a big deal, just

pitch in a bit and move the ball forward until the other team member gets back into the

office. You are curtly met with “That’s not my job” and nothing else. You know that this

person can do what you are asking them to do but they say that it’s not their job? Are

you kidding me? Is that even still in people’s vocabulary to say that anymore?

2. Checking Phones During Meetings

Yes…today’s smart phones are very smart. But, they’re also very disruptive and

distracting. The second thing that really gets on my nerves as an IT Project Manager is

the number of people who coyly check their phones during meetings and don’t pay

attention. They are texting, emailing, surfing the web and who knows what else on their

Smart Phones.

You can tell who they are too. They have a wry little grin on their face as if they’re the

only person who is in on this personal private little joke. They’re the ones with the look

on their face that they’re so important and plugged in to everyone and everything else

that it trumps the meeting they are attending in person!

3. Laptops at Meetings

This takes the Smart Phone distraction to another level. This

is where people bring in their laptops to meetings that they

need to be focusing on and go to work as if the conference

table is an extension of their desk. Did we call this meeting

for the purpose of having very smart and highly paid

employees watch you check your email or complete a

spreadsheet? I don’t think so. We called this meeting and invited you to it, in order to

have your rapt attention and contributions. Please stop bringing laptops to meetings.

4. Being Late to Meetings

Since we are on the Meeting theme of things I hate as an IT Project Manager, here’s

another one that drives me crazy. I take great measures to schedule meetings at a time



that everyone can attend. I account for the time that it takes for people to get from one

meeting to the next. I may even call you and ask you what the best time would be to

work in with your schedule for a meeting that is coming up.

Despite these Herculean efforts at scheduling a meeting to work around your

schedule…you still show up late! I’m not talking about every now and then kind of late.

We all do that. Things come up, meetings run over and the best of plans get waylaid, but

that’s “every now and then!” You‘re different. You’re 5-10 minutes late to EVERY

meeting.

It’s not just mine. It’s EVERYONE’S meetings. You have such a high regard for yourself

that you feel as if it’s OK to make up to a dozen people wait until it fits into YOUR

schedule to show up.

5. Overreacting

The fifth thing that I hate as an IT Project Manager is

when people overreact to the situation at hand. Let’s

face it, things get off track every now and then on any

project. The unexpected may occur, or it’s discovered

that something may have to be redone, or started from

scratch.

It’s not the end of the world and you are not up for an Academy Award. There’s no

reason to throw your hands up in the air and act like the entire world is resting on your

shoulders. Leave the Drama Class back in High School and act like a professional. Deal

with the circumstance at hand, ask what you can do to help out and get things back on

track, and just know that someone will do the same for you when you drop the ball in

the not so distant future.

6. Not Giving Accurate Completion Status

How long can something be 98% done? I mean, seriously. There has only been 2% left to

go on this particular deliverable for as long as it took to complete the original 98% of the

deliverable. As an IT Project Manager, I may not know as much as you about the

complexities and nuances of what you are working on, however, I can do some simple

math. If a deliverable has been 98% complete for a ridiculous amount of time it means

that either that deliverable is not being worked on or it has run into some technical



difficulties. Shoot straight with me regarding completion status and we can work on

getting things figured out together.

7. Not Giving Accurate Estimates

Some resources feel as if they can pull an estimate for how long something will take out

of thin air. Or, they may feel as if every deliverable they are asked to work on will take

the same amount of time for everything. I worked with a resource that whenever I

asked how long something would take it was always the same answer…40 hours. Didn’t

matter how large or how small, it was always going to take the same amount of time.

This undoubtedly contributed to the problems we were experiencing in #6 above and

just became no longer believable.

8. Blame Storming

This is the terrible activity that ensues when something goes wrong on a project and the

first thing everyone does is to look for whom else to blame. This can be manifested in a

quick, reactionary outburst to when the defect is first discovered (“she did it”) to

carefully orchestrated sessions that include upper management and departments within

the company lining up against each other to make sure blame is squarely affixed to

someone else.

Rather than get caught up in this type of mentality, you need to fix the problem first and

then objectively and with the right motive, find out why it happened. Plus, if you were

the cause of the problem then you need to stand up and own it yourself as well.

9. Withholding Information

This is what I would call an “error of omission”. For example, the IT Project Manager

may come to you and ask if everything is on track for the project to be deployed on the

original date in the schedule. You are key to this delivery and implementation and you

say “we should be all set”. What you fail to let the IT Project Manager know is that you

are not going to be in the office that day. It may or may not be a good reason, but

regardless, this is a huge fact to leave out of the conversation and something that would

be very helpful to know. Just don’t answer the “letter of the law” of what is being asked,

but go beyond that and answer the “spirit of the law” of the intent of the question.


10. Blame it On the IT Project Manager

It’s no surprise that IT Project Managers will make their fair share of mistakes. We all do.

But, it should also be no surprise that we are all adults that are working together. If you

make a mistake and it was something that you should have known as a professional

technical resource, you can’t blame everything on the IT Project Manager. “I didn’t do

this particular key thing because the Project Manager didn’t tell me to do it” is not an

acceptable answer for every mistake you may make.

What is an IT Project Management Workaround?

There are many things that occur during a complicated IT project that will allow room

for this sin of “workarounds” to come to the fore. No matter how much you plan,

anticipate, manage risks, and monitor your IT project, there are always going to be

things that go wrong or cause your project to go off track. These can be grouped into

the following categories:

Not Expected – The first category that could possibly introduce a workaround

involves things that are “not expected.” These could include such surprises as a

change in management, a sun-setting of a particular technology, or resources not

being available. These are all items that may not have been considered in the project

plan or did not appear on the radar of any risk management sessions that were

conducted.

Not Accounted For – The second category that could possibly introduce an IT Project

Management workaround involves those items that should have been accounted for,

but were missed. Examples of this could be: not scheduling enough time to test the

software that is being developed; and/or not setting aside enough time for a proper

solution to be architected.

Out of the Blue – The third category that could cause

one to ‘sin’ includes everything else that could

compromise a project and prevent it from being

completed on time with the proper quality controls

or on budget. These could range from someone in

your internal organization throwing a bombshell at

the last minute, to a client accelerating the project



schedule.

When any of the above situations occur that are not expected, not accounted for, or

come at you from out of the blue, then you have a choice to make. People are going to

come at you with options and suggestions for how to keep things on track during these

tenuous times.

The majority of these suggestions will include the phrase (or variation thereof)… “We

can take a shortcut and still get this done on time.” When you hear this phrase…Run!

After all, IT Project Management workarounds are nothing more than a shortcut that

should not be taken.

There’s a saying that “if you do something quick and dirty, the dirty will last a whole lot

longer than the quick.” Even if you were able to save some time by utilizing a shortcut,

when things begin to unravel and management or others start to ask why something

was a done a certain way, everyone will forget the time that was saved. All that will

remain to be exposed is the nasty, sinful shortcut that was taken and how it

compromised the integrity of the project you’re managing.

How Can You Overcome IT Project Management Shortcuts?

There are a number of ways you can fight the tendency to give into workarounds and

shortcuts as an IT Project Manager. Here are three suggestions.

Just Say No – Sometimes you have to be the bad guy. You don’t have to, nor should

you, say YES to every suggestion and idea that comes to you from the team. You

don’t want to stifle their creativity and ability to offer suggestions, but you’re

ultimately the one that’s responsible for the success (or failure) of that project. If

taking a shortcut isn’t a good or responsible path to go down, then don’t take it.

Be Transparent – A second option (if you do want to consider an IT project

management workaround) is to be entirely transparent with the decision. Make sure

that anyone and everyone that could be negatively impacted by this decision is

aware of the potential risk and is in agreement with moving forward. Depending

upon the nature of your organization and how good people’s memories are, you’ll

probably want to get this in writing. If, and when, something goes off track because

of this decision, then you can refresh everyone’s memories that this was a collective

decision that, at the time, appeared to be the right one to take. Part of this

transparency should also be the fact that this could run the risk of delaying the


project even longer or costing more. You need to make sure that everyone is

comfortable with this decision and understands that there is the possibility of things

going terribly wrong.

Fight for It – You’ll be in a better position to fight for the right to do things the right

way once a couple of shortcuts have been taken and the project has gone south.

“Remember what happened last time?” Or …“We were in a similar situation as this

and this is what went wrong”. Either of these will

certainly refresh people’s memories and hopefully jar

them back to their senses if they start going down

the slippery slope of wanting to take a shortcut. Fight

the urge to get involved in a shortcut or workaround

as much as possible. The consequences are not

nearly as profound as succumbing to one of the

traditional (biblical) cardinal sins; however, they

certainly can make your professional life much more complicated. If you don’t feel

that it’s the right path to go down, then don’t let anyone convince you otherwise.

This ability to stand up and rely upon your experience as a professional project

manager will help propel your career to new and fulfilling heights.

10 Tips for Better Project Management in IT

If you have the privilege of working in project management in IT, are there certain things

you can do to make the most of this exciting and highly uncertain environment? The

following 10 tips can you make the most of project management in IT.

1. Keep Your Eyes on the Big Picture

Yes, there are a million small things that can go wrong at any moment

in time in IT Project Management. Resources can become sick,

requirements are missed, incompatible technology is used, and

systems can go down. And yes, these things will happen. You can

count on something going wrong almost as soon as the project starts.

However, don’t let these minor setbacks distract you or derail you

mentally from the outset. Keep your eyes focused on the end goal

and what the project is supposed to accomplish. Doing this will allow


http://www.projectmanager.com/resources/wp-content/uploads/2012/08/iStock_000004806476XSmall.jpg


you to overcome the minor things that go wrong, make the proper adjustments, and

continue to drive everyone toward project completion.

2. Keep Your Eyes on the Details

This may sound contradictory to “keep your eyes on the big picture” but it’s not. Rather,

it’s complementary to keeping your eyes on the big picture. When it comes to project

management in IT you need to work with both the big picture in conjunction with the

details.

Think about it this way….when you drive you are paying attention to both the big

pictures and the details. You’re looking through the windshield to keep your eyes on the

road, watch for oncoming traffic, determine where you are by watching the road signs

and determine where you are going.

However, you are also paying attention to the details when you look down at your

dashboard. You know how fast you are going and adjust your speed accordingly. You

monitor your gas situation and whether the car’s temperature and oil gauges are within

the correct parameters. It’s the combination of the big picture and details that allows

you to arrive safely at your destination.

3. Create Allies and Not Adversaries

Two things happen when you work with other departments in a company if you are in

project management in IT. You will either get along with them just fine, or, the

relationship may deteriorate and become adversarial in nature. That is the last thing you

want to happen.

Make it your mission to constantly look at everyone in the company as being on the

same team and not opposing each other. This takes work, effort, and time on your part

and may not always be reciprocated by the other person. However, you will find by

having this attitude your project management job will be that much easier to

accomplish.

4. Don’t Make Assumptions

I won’t even say the fact that we all know the expression about making

assumptions…however, it’s true. You do not want to EVER make assumptions if you

work in project management in IT. You can’t assume that just because someone said a


deliverable is complete…that it is. You want to take people at their word; however,

people have different definitions of “complete”. If you take someone at their word that

something is complete without following up you may be in for a rude surprise. A good

rule of thumb to follow is “trust but verify”. It will help keep everyone out of harm’s

way.

5. Always Ask “Why?”

Just because something has been done a certain way for years does not mean that it has

to be done that way for years to come. It’s your job in project management in IT to

always ask the question “why does it have to be done this way?”

You may find that the answer is “because we’ve always done it this way”. If you come

across that answer then this is a prime opportunity to dig a bit deeper and see if there is

a better way to accomplish the task. You’ll find that you can uncover so many areas for

process improvement that you will begin to ask “why?” at as many opportunities as you

can.

6. Be Extremely Clear and Precise

There’s already enough ambiguity and confusion in project management in IT that you

don’t need to add more to the mix by being unclear in

your direction. Take the time necessary to make sure your

project team is 100% clear about what needs to be

accomplished and that they have no questions. If you find

yourself being vague or general about a task that is to be

accomplished then you may find that you don’t

understand it very well yourself. Go back to the drawing board to make sure you have a

crystal clear grasp on what you are asking someone else to do; otherwise, you could

cause someone to head down the wrong path.

7. Respect Other People

Some project managers may have a tendency to look down on their resources or just

treat them like commodities that just need to do what they say. Don’t allow yourself to

get caught up in this way of thinking. Always view your team members as subject matter

experts in the areas they are working in just like you are an expert in project

management in IT. People know when you don’t respect them because you talk down to



them, come across as condescending, or even dismissive. Stay away from these traits

and you will get exponentially better performance out of your team.

8. Manage AND Lead People

You wear many hats if you are an IT project manager. Two of the biggest hats you wear

are that of being a manager and a leader. Many times you’ll find that you have to fill

both roles concurrently. This will allow you to see the big picture as well as pay

attention to the details that was discussed earlier.

You need to motivate your team enough that they can see the goal line, but then you

also have to provide them enough management direction that they know exactly how

they will reach the goal. Keep them inspired and driven at the same time.

9. Catch People Doing Things Right

Do you like how one of your team members just performed or how they completed a

task? Do you want them to do the same thing again? Then call it to their attention. A

great way of predicting future performance is telling somebody what a great job they

just did. This will also make it easier to tell them what they need to work on if they are

not performing to your expectations. They’ll know your motive is not to be out to get

them but rather to help them improve themselves.

10. Watch Your Attitude

Have you been around the person that is overwhelmingly negative?

When someone asks them if they can help do something they say they

can’t. When someone asks them if something is possible they say it

isn’t. When someone asks them to change their disposition they say

they won’t. That type of person will bring anyone down in just a

matter of days. There’s no room for this type of attitude when you are

dealing with project management in IT. You need to become a “can

do” person that will at the very least look into the possibilities of what can be done to

make something work.

What type of project manager are you? The more of the traits you have above the

better you will be able to navigate and overcome the complexities that surface when

you manage IT projects.



IT Project Plan Completion

What do you do now that the IT Project Plan is complete? You have undoubtedly taken

care of all the administrative side of things when it comes to closing out your IT project

plan. If you want to distinguish yourself as a project manager that takes things the extra

mile, there are a number of small things you can do that will make a big difference on

your project. Below are three suggestions you may want to consider:

1. Document and Acknowledge Team Members’ Contributions

Throughout the execution of the IT project plan

you can remember certain things that team

members’ accomplished on the project that really

made a big difference. The best way to document

these accomplishments is to make a note to

yourself the moment that they occur. It’s easy to

set up a Rule in Outlook or whatever e-mail

program you use that will automatically file emails

with a certain word in the title.

Whenever you catch someone on the project doing something exceptional, send a quick

email to yourself with a brief description that will allow you to remember what they did

at the end of the project. Include the Word in the subject line (for example REVIEW or

COMPLETION) that will automatically allow Outlook to file these accomplishments in a

special folder until you are ready for them.

When the time comes to acknowledge team members contributions you can then open

this file of real-time accomplishments and begin thinking about the best way to provide

them with recognition.

There are a number of ways this can be done. You can write a sincere and genuine thank

you card to the team member that gets very specific with their accomplishments and

thanks them for how the contributed to the success of the project. Or, you can write an

email to that person’s manager or supervisor and make sure they know the specifics of

what this person did that helped move the project forward. If you have a bit of a larger

budget you can set-up a lunch or dinner and publicly recognize team member’s

accomplishments in front of their peers and colleagues.



The trick is to make sure you are rewarding the behavior that you would like to see on

future projects. You will undoubtedly work with these people again and if you really

appreciate their timeliness, accuracy, or desire to go above and beyond make sure you

tell them. They’ll appreciate you taking notice of what they’ve done and will most likely

continue that behavior on your next project.

2. Let Others in the Company Know the Project is Complete

This step falls into the category of ‘marketing’ your project and letting others know what

the project will do for the company. Letting others in the company know about project

completion is not necessarily something that is included in the IT project plan, but it is

very important nonetheless.

Good communication within companies is

something that is typically lacking. If you

want to let others know about the success

and completion of your project then you will

have to come up with ways to get the word

out.

Where can you start to ‘publicize’ the

completion of your project? Your company’s

marketing department. Marketing departments are constantly looking for good content

to promote and get out to everyone. Depending upon the nature of the project that was

completed, this could be something that is as simple as putting in the company

newsletter (tell them you’ll even write the article) or letting the entire world know

about it by creating a Press Release and distributing it for everyone to read.

Don’t have a marketing department or they may not have enough bandwidth to get the

word out on your behalf? You could then take it upon yourself to put together a brief

email together and distributing it to key stakeholders within the company to let them

know the project has been completed and what this means for the company.

3. Communicate Back the Results of the Project to the Original

Team

This step is certainly something you won’t find in any IT Project Plan, but once some

time has passed you will know the results of the project. You should compile these



results and communicate them back to the original project team. For example, the

project may have been implemented in order to save time, increase revenue, cut costs

or some other important business initiative. Once a month or two has passed you can

interview the beneficiaries of the project (either internal or external) and see how it is

meeting their expectations. Capture key metrics that you can share with the team and a

testimonial or two that highlights the benefits this project has brought to those who are

using the results. Your team will appreciate the time you took to compile this and let

them know that what they are working on is worthwhile and appreciated.

What if you find that the results are not as originally anticipated in the IT project plan?

This is also a great time to uncover this truth. It’s better to hear this up front while

something can be done about it rather than 6 – 12 months down the road when it’s too

late. Maybe the department that is using the results of the project did not see all of the

automation that was promised to save time. This is a great time to dig into the details

and see if there is anything that can be done to make things better.

There’s nothing like making it to the last item on the IT project plan and reflecting on a

job well done. There’s a feeling of pride and accomplishment that is reserved for only

the most tenacious of project managers that sees projects all the way to completion.

Take your project completion to the next level by implementing the three steps above.

Are they critical to the success of your project? No. Will they help you with every project

you undertake from this point forward? Absolutely! You’ll find that by taking the extra

time to do the steps above that your future projects will become that much smoother

because of a motivated project team, informed stakeholders, and appreciative clients!

IT Project Planning and QA

IT Project Planning and QA may not necessarily see eye-to-eye all the time and this can

feel like a knock-down, drag out bout of tug of war. The following article will highlight

some of the causes of this conflict and what can be done so everyone is pulling in the

same direction.

IT Project Managers and Quality Assurance people are cut from a different cloth. Each

respects what the other does, but they definitely look at the world through different

lenses. Below are some of these differences that could be a cause for contention from

time to time:


The Pursuit (or Not) of Perfection – Any

QA person that is worth their salt sees

things in a very black and white point of

view…as they should. The functionality

that is called for in the IT project planning

process either works or it doesn’t. The

numbers that resulted are either right or

they are wrong. The integration from one

system to the next is either connected or it’s not. There is no room for ambiguity,

grey areas, or even “close enough” when it comes to doing a good job in QA. Test

plans and scripts are designed for a reason and the answer after running those tests

is either Pass or Fail. A project manager, on the other hand, works in a very different

type of environment. The IT project planning process is one that is full of different

shades of grey. Requirements and priorities are constantly shifting. Resources come

and go based upon what is important to management at that moment in time.

Depending upon the circumstances and downstream impact, there is room for ‘close

enough’ if there is a greater good accomplished by moving parts of the project

forward. It is this different view of the world in the IT Project Planning process that

may cause these two people to stand toe to toe and start tugging on the rope.

Higher Stakes for QA – Sure, when everyone is involved in IT Project Planning it looks

good on paper about who is going to be responsible for what: The Engineering team

is responsible for building the product, the Documentation team is responsible for

putting together great instruction and training manuals, Business Analysts are

responsible for making sure the proper scope is captured, and Project Managers is

focused on coordinating and orchestrating everyone’s efforts. But, QA ultimately has

to sign off on the deliverables produced from each of these departments either

passing or failing. Let’s face it…when something goes wrong on an IT Project one of

the first questions asked is “how did this make it out of QA?” A close tie for the

second question, of course, is “who was the project manager?” But, ultimately it is

the responsibility of QA to approve something as ready to go.

Dates – One final point of contention between IT project planning and QA has to do

with dates. Project managers are obsessed with dates. They always want to know

exactly when something will be done, how much of something will be done, and if

just one minute slips on the schedule they are demanding an explanation of why and



asking what can be done to gain the minute back.QA, on the other hand, is focusing

more on the job getting done right.

They understand there are deadlines to

meet, but they also understand that

whatever it is they are testing needs to

be 100% correct. They are comfortable

with the fact that you can’t rush

perfection nor assign a cold, hard, fast

date to anything as complicated as the

IT projects they are responsible for

approving. This leaves a project

manager with a quizzical look on his face as he tries to figure out how he can assign

dates around this type of non-committal ambiguity.

The above three areas certainly lend themselves to turning into a recipe for disaster.

But, take heart. There are ways IT Project planning and QA can work together to

accomplish the same objective.

Can’t We All Just Get Along?

Yes…it is possible for project managers and QA resources to get along with each other. It

will require effort from both sides, but here are some suggestions you can start to apply

as a project manager.

Get QAs Input – Never, ever, ever move forward with the IT project planning process

without getting their input. This cannot be stressed enough. If you want to guarantee

that you’ll be on opposite sides of the rope then just fill in the blanks for them on the

project management plan and see what happens.

Establish a Good Relationship – QA resources are people too. And, they are people

just like project managers. They have kids, they play sports, they do stuff on the

weekends. Yes, sometimes you may not feel this way in the heat of battle but, it

never hurts to establish some sort of common ground with these valuable resources.

Plan on Things Taking Longer – Even if you do have a good relationship with QA and

get their input up front…plan on things taking even longer than they anticipated.

Until things are down to a science, it’s not too far-fetched to think that some things



will take 2 to 3 times as long as what was originally estimated. Plan for this and you’ll

be able to navigate through the surprises quickly.

Defend their Position – Do you really want to make allies with your QA team? Do

you want to maybe even get them to the point someday where they could utter the

words “close enough” out of their mouth every now and then? Then stand up for

them. They have an important job to do. If they are not given the proper time

necessary to do their job then everyone ultimately suffers.

Project Management and QA will never see eye-to-eye and that’s OK. It makes the work

environment interesting and it takes a certain amount of tension to crank out good

products. Do all you can to bridge the gap and find yourself on the same side of the

rope. You can then focus on beating the competition!

Apologetic Project Management in IT

Project Management in IT is complicated for a number of reasons. First and foremost is

that there is typically not a solid, tangible, wrap-your-hands-around-it type of

deliverable that is produced in an IT environment. It’s all bits and bytes. The results end

up on monitors, on the web, and in the cloud. The intangible nature of the work

produced makes IT project management particularly tricky. Then, add the following

complexities:

Very Smart People – There are smart people in all

professions. They have amassed a certain amount of

specialized training, education, and experience that

makes them good at what they do. People that work in IT

are pretty smart as well. As a matter of fact, those that

have a natural ability or knack for the work they produce

can be eerily smart. You can see a brilliant DBA or

software engineer work through all the different

scenarios in their head in a split second and come up

with the best approach to solve the problem at hand.

You want these types of people on your team. They are

usually very good to work with. However, if you don’t “know

your stuff” they will quickly see through the smoke and become a different



management experience altogether. They will make you feel as if you are interrupting

them or that they are too busy for you because you are not adding value to them and

their position. You then find yourself in the situation where you feel hesitant to

approach them and then start each sentence with “I’m sorry, but…”

Very Experienced People – A different take on ‘very smart people’ are those people

that are very experienced. This becomes even trickier in IT project management

because everything is changing so quickly. Exponentially new technologies come and

go every six months and the real talent of very experienced people is not necessarily

how much they know (ask the experienced COBOL programmer how easy it is to find

work these days) but rather how quickly they can learn and come up to speed on

new technologies. You want very experienced people on your team as much as you

want very smart people on your team. But, be prepared for a similar challenge in

managing these very experienced people. They have “been there, done that” and

have little time nor patience for someone that is just coming up to speed. You need

to dot your ‘i’s and cross your ‘t’s as much as you can prior to interacting with a very

experienced resource.

Very In-Demand People – There’s no surprise that very smart and experienced

people are also going to be very in-demand as well. They’ll be glad to help out as

much as possible, but you need to respect their time. You will get a lot more done in

your project management in IT job if they feel you are highly conscious of the value

of their time.

Check Your Apologetic Attitude at the Door

How can you be successful with project

management in IT working with the types of

people described above? Much of your success has

to do with your attitude when it comes to working

with highly educated, skilled, and talented people.

Project Managers can be loosely categorized as

taking two different types of approaches when it

comes to managing these resources:

What Can I Do For You? – One approach to

managing projects is to serve as a “resource”



for your resources to tap into. You go around and ask your team what areas they

need help in, what obstacles are in their way, or anything else they need you to

handle. This approach works well if you are working with newer resources that do

not have a lot of experience. They will appreciate the direction you are providing and

knowing that you are looking out for their best interest. Experienced, smart, and

busy resources may not view things the same way. These people have been in and

around business for years.

They know what needs to be done, know how to power through their own issues,

and have an ability to focus on the end result until it’s achieved. They may view you

as a bit of a pest if you flitter around them incessantly asking them what you can do

for them. You’ll soon find yourself “apologizing” for checking in with them so often.

What Can You Do For Me? – The other side of the coin is that you are expecting

certain things of them and you are basically asking them what they can do for you.

This is a fundamental shift in your attitude about project management in IT but one

that will serve you well as you progress in your career. Rather than being apologetic

about having to follow up with them all the time, you will find yourself in more of a

position of strength and control. You know that these people know what they are

doing. You know they understand what a deadline means and keeping their word is

important to them.

They respect the fact that as a strong project manager you are coming to them with

the attitude of “in order for this project to get done, this is what I need from you.”

They will react positively to this type of direction as you continue to establish a

strong relationship with them on future projects.

One additional word of caution if you fall into the category of “what can I do for you”

project management: Don’t be so eager to please. Your job is not to garner the approval

of smart, educated, busy people. Your project management in IT job is to get the job

done. That is what will ultimately establish the respect you need to propel your project

management career to new heights.


4 Problems About Doing It All

Yourself

Your plate is already full if you are performing

your job in IT project management to the best of

your ability. There is planning, meetings, reports,

escalations, mitigations, counseling, stewarding,

babysitting and a host of other official and non-

official project management activities that fall

under your purview. It is highly unlikely that

anyone will come up to you and say “can I help

you with that?”

It’s not that people don’t care; it’s just that everyone else’s plate is extremely full

already as well. It’s up to you to delegate to others in IT project management.

Otherwise, you will experience the following side effects of trying to do it all yourself.

1. You Will Slow Things Down

If you are dumb enough (yes, dumb enough) to pick up a task or activity that is on the

critical path of a project, then you will almost for a certainty slow things down. Yes, it’s

tempting to pick up an activity that needs to get done, especially if you have experience

in that particular area. But, with all of your other IT project management responsibilities

you will quickly find that these critical path items will suffer.

2. You Will Burn Out

Let’s say you decide to pick up these items that are on the critical path in addition to

your IT project management job. You decide to not delegate these to someone else.

Sure, you may be able to pull double duty for a short period of time. This means you

come in early, stay late, and most likely work some weekends as well. Over the long haul

this will begin to negatively impact your mood, your relationships with others, your

patience, and even your health.

3. You Will Make Mistakes

Since your mood, relationships, patience, and health are deteriorating because you

think you can do it all yourself…you will make mistakes. You are tired. You are frazzled.



Your judgment becomes blurred and your insight and experience begins to be replaced

by raw, exposed, non-objective emotions. It is when you get into this state of mind in IT

project management that mistakes will start to occur.

4. Your Team Will Suffer

Your role in IT project management is to be a leader. Your role is not to be a doer. You

have a team of people that are doers. They look to you for direction, guidance,

navigation, obstacle clearing, and peace of mind. You are doing them a disservice if you

join their ranks and get sucked into the details and quagmire of the project like

everyone else. You need to rise above the morass and provide a crystal clear path to

follow.

There is no compelling reason to feel like you have to do everything yourself based upon

the list above. It doesn’t work and you, your team, the project, and ultimately the

company can be affected due to this erroneous mindset.

Are There Things You Shouldn’t Delegate?

Now that we’ve made a strong case for delegation in IT project management, are there

certain things that you should not delegate to others? The following principles can be

applied to help you make this decision on what you should keep for yourself.

Keep Those Activities that ONLY YOU Can Get Done

– There are activities that only you in your IT project

management role can get done. This may be

meeting with the executive team to provide an

update on where things stand. Or, you may find that

you need to work with a troubled client to smooth

things over from a miss that happened on the

project due to poor communication. These are the

types of things that you, and only you, can

accomplish in a graceful and elegant manner and not something you would delegate

to someone else.

Activities You Can’t Clearly Describe – There are activities that come up in IT project

management that are hard to describe. When you work in the technology field you

will find that there are problems that are vague and solutions that are shrouded in

complexity and mystery. If you find yourself having a hard time describing what you



need to get done, you will most likely want to keep this for yourself until the

objective is clear enough in your mind that you can describe it someone else.

Otherwise, you may send someone on a wild goose chase and burn up unnecessary

cycles of time.

(Possibly Do Some) Non-Critical Path Items – The ideal in IT project management is

that you don’t own anything directly other than managing the project. However, you

may find that your team is short-handed, someone is out sick, or you may even have

a little extra time to help out in one area or another. If you make the decision to pick

up a task yourself for completion and not delegate it to others, then make sure it is

something that is not on the critical path.

How to Effectively Delegate

There are a number of degrees of delegation you can take advantage of in your IT

project management role. Below are a few you may want to consider.

Educate yourself – You can assign someone on your team to go gather all the facts

and then come back to you to discuss the path best to take.

Give me a recommendation – You can assign someone with the responsibility of

assessing the problem and then coming back with the best course they would

recommend.

How are things going? This method assumes you have a lot of faith in the person

that has been assigned the task that all you do is check in with them every now and

then to see how their activity is coming along.

Don’t pass go – Set a point in time that they come back to you to discuss how much

further you would like them to go on a particular task.

Keep going until I say stop – Give someone the opportunity to take a task as far as

they want to and not stop unless you ask them to stop.

Get it done – This is the ultimate in delegation. Here’s the problem, go fix it, and

then come back and tell me what you did. You need to have a lot of faith in the

person when you go down this path. This is ultimately how you want to operate with

your team.

Delegation in IT project management is no simple task. There are a lot of moving parts

and complexity on any project you are managing. You want to make sure you don’t fall


into the trap of having to do everything by yourself otherwise you, your project, and

your team will suffer because of that bad decision.

Keep Arrogance out of IT Project Management

There are a number of reasons why good companies go bad and IT project management

suffers as a result. The following are a few of these reasons:

People are Really Smart: People that work in

technology are no dummies. They’ve either gone

through years of schooling, have taught themselves

through hard-work and perseverance, or a

combination of both. These people have college

degrees, MBAs, Ph.D’s and other impressive

credentials hanging on their walls that show off their

intelligence. Unfortunately, if not kept in check, this

can cause people’s heads to swell a bit more than

they should. This results in IT project management

challenges when it becomes hard for these people to

see that there are other paths that can be considered that may yield better results.

Technology is Exciting: There’s a lot of adrenaline flowing when you’re working for a

company with a whole bunch of smart people that are doing things that have never

been done before. Breakthrough after revolutionary breakthrough causes people to

really get into what they are working on and the results. Success breeds success and

unfortunately, sometimes success can breed arrogance.

Lots of Money: Venture capital funding flows freely. People start walking around

with a bit of a swagger in their step as they delude themselves into thinking this ride

will never end.

Really smart people working on exciting technology with lots of money can cause people

to lose focus on the reality of business. Therein lies the IT project

management challenge. You end up working with:

People with Blinders On: Team members, managers and executives can become so

myopic in their vision that they block out the rest of their environment. They block

out what is happening in the marketplace, they block out what their customers are



telling them, and worse yet, they can even block out that little voice in their head

that says the path they are on is not working.

People Who Are Self-Consumed: Departmental silos can begin to form in this type of

environment. It can even be taken down to the next level to the point of Individual

silos being established. People can hole themselves up in their offices and cubes and

not interact or engage with others on the team. This presents another set of

challenges for IT project management

People Who have “Not Invented Here” Syndrome: There is nothing that anyone on

the ‘outside’ can do that can compete with what has been developed internally. This

causes missed opportunities and loss of efficiencies in many areas.

It is very hard to adjust this type of thinking once a company has slipped into this

mindset. What can be done? The answer can be summed up in one sentence…never let

the arrogance of technology overcome the common sense of business. That’s all there is

to it. Your IT project management role should include bringing a dose of business reality

to everyone. You can keep tabs on what is going on outside the company. Talk to others

about similar situations and experiences and how they have solved challenges. What’s

more, never lose sight of what the customer needs and wants. In doing so, you can keep

arrogance out of project management in IT!

How to Plan a Software Project that Works

To successfully plan a software project you must invest time up-front. There are many

various activities that you can invest your time on when it comes to planning a software

project, the following list provides some insight into how to plan a software project that

works:

Identify ALL Users

The emphasis here is on ALL users. In addition to the direct users, there is going to be a

multitude of indirect users. There will be those who use the software every now and

then to get their jobs done. There will also be those who receive or benefit from the

results of the application. For example, management may use certain reports that the

application generates. Make sure to include them in the requirements gathering session

even if they don’t use the program directly themselves.


I learned a huge lesson many years ago when it came to learning to plan a software

project and identifying users. I thought I had identified everyone that had anything to do

with the application…and I had uncovered a multitude of people. But, there was one

fellow in the deep recesses of the store where the software was being implemented

that I missed. This fellow was discovered as the software began to be rolled out across

various stores. This was a subject matter expert that brought the entire roll-out to a

grinding halt because it did not include certain functionality that he thought (and others

like him) was mission critical. Make a list and check it twice! Be sure you have anyone

and everyone involved in the requirements gathering process as possible.

Identify their Credibility

A word of caution when you create the list from above, when it comes to learning how

to plan a software project. It is absolutely vital that you establish the credibility of those

who are providing input into the plan. True story…we had a team that just went into a

requirements gathering session where all the stakeholders had been identified. There

was some great feedback coming back from the users, but then there was one voice in

the room that was providing general and generic feedback. “Make it better”, “It needs

to be faster” or “It’s too hard to use” he would say. After continual feedback like this

throughout the morning, we asked him for specifics. “Exactly what is it that needs to be

better, faster or easier to use”, we asked. “I don’t know, I’ve never used the program”,

he replied. This is an easy trap to get caught in when you are first starting out on how to

plan a software project that works. Be careful to not go down the path of a user that is

not offering real value for what needs to be included in the application. The example

above is an extreme case, but there are times when someone will blurt out something

just to have something to say. Make sure you vet out what you would consider to be

real requirements and those that are just being thrown out.

Capture Everything

At this point in the process of learning how to plan a software project it’s important to

capture every little thing that is thrown out there. You have identified the right audience

and you are zeroing in on only those who have credible and meaningful contributions to

make to the plan. Prepare a long list of everything that should be included with enough

information about each item that you will know what it is for future reference.


Prioritize

This is the point of how to plan a software project that you begin to prioritize the list

that has been identified above. The best way to do this is break it down into 3 buckets:

1) Absolute must-haves (business can’t be done without this) 2) Nice to haves: business

can be done without this, but this will make it easier 3) Everything Else: cosmetic or very

minor changes or additions. You now end up with ideally a very short list of absolute

must-haves that your team can begin working on.

Dig into the Details

You can now explore these absolute must-haves in greater detail. Ask questions about

what this feature needs to accomplish in the software. Challenge assumptions. Always

ask ‘why’ is this something that is important to include or to operate in a particular

manner. This will provide you with enough detail of what needs to be accomplished that

you can turn it into a project plan and communicate the specifics to your team.

Deliver

Finally, when it comes to how to plan a software project that works, you must deliver.

There are a ton of steps between planning and implementation, but if you have done

your homework up-front and spent enough time in the requirements gathering stage

the end result will turn out much better.

One note: If you have the luxury of having Business Analysts on your staff, then the work

above is best left in their hands. They know how to identify and uncover those elusive

little things called requirements that, if missed, can bring a project to a grinding halt.

Many companies may not have this luxury and it falls into the hands of the Project

Manager to make sure this work is complete.

There is much uncertainty in planning missions to Mars. Despite this fact there are those

projects that are wildly successful and delight everyone. You can have the same

experience when it comes to planning your software projects. Take the necessary time

up-front and save yourself a tremendous amount of time and disappointment later in

the cycle.


Removing the Smoke Screen with

IT Planning Software

The classic Smoke Screen approach has been

around for a long time and worked effectively for

many years. Unfortunately, some of the

resources that work on our projects have learned

to use the Smoke Screen very effectively

themselves. This is how it works…

You are in a status meeting, reviewing the plan that was generated from your IT project

planning software. You are going around the room and everyone is providing an update

on where things stand, what’s next, and what may be in their way preventing them from

moving forward.

You come around to one of the Developers on the project. “Bill, how are things looking

for you?” you ask. “Well, not so good…” they start off. You brace yourself for what’s to

come because you know it can’t be good.

“I was only able to complete 20% of what had been assigned to me with the IT planning

software”, they continue. When you press them for why, they start throwing out

reasons that have nothing to do with the real reason why they are late. “Well, I was

waiting on a file from the client in order to continue testing”, they say. You know good

and well that the previous file would have been just fine to continue testing. “Well, I

wasn’t able to get a connection to the right server in order to move the code”, they

continue. You know good and well that they delayed for over a week in getting the

necessary paperwork filled out that would give them access.

At this time you notice that the room is beginning to fill with smoke. The real reason

they are behind is getting muddled and confused. Other people are being implicated

that have nothing to do with the reason why this particular resource is running behind.

Confusion takes over the meeting and this particular resource secretly disappears in a

cloud of smoke. WHOOSH! Foiled again!

The above scenario sounds like it’s straight out of a comic book, but it’s not. It gets

frustrating for a project manager who is trying to manage a project using IT planning

software.

http://www.projectmanager.com/resources/wp-content/uploads/2012/11/typical-smoke-screen.jpg


How to See Through the Smoke Screen

There are things you can do to make sure you are not bamboozled by this smoke screen.

The following are some suggestions you can use to see through the smoke:

Know Your Facts: It’s important to keep up with the facts that have been occurring

on the project. You can use your IT planning software to know exactly when the work

was assigned. Keep up with each and every email that begins to reference issues with

work not being able to be complete. These issues can begin to surface as just a “by

the way…I can’t do this” comment nestled in at the end of the email. It may seem

harmless enough early on. But, over time, this issue (that may not be directly related

to a delay in the task) may become the basis for the smoke screen later on. Jump on

these issues early and often! It may be simple to just gloss over an innocuous

statement that something is being held up. This only adds fuel to the fire…which

adds smoke to the status. Get out of your seat and walk over to the resource that is

having the issue. Find out what is really going on. Determine if they truly are at a

stand-still or if there are plenty of other things they can be working on in the

meantime.

Make Sure You are at the Occasions Where the Smoke Screen Can Appear: Smoke

Screens are very discretionary where they appear. There may be a status meeting

where upper management or the resources manager is in attendance. The person

knows that they haven’t finished everything that has been assigned to them in the IT

planning software. This is a prime time for a smoke screen to instantly appear. Do

you want to guarantee that it will appear? Don’t show up to the meeting! That’s

right. The minute someone knows you won’t be there to refute or challenge what

they are saying, you can be assured the smoke will make an appearance. That’s why

it’s so important to know your facts from the step above. You can objectively recall

emails, conversations, and other details about why something is really behind, not

just the excuse that is being presented. Not invited? If it’s about your project then

you better invite yourself.

Don’t know about it? If it’s about your project then you better know about it.

It’s part of your job as project manager to make sure these kind of meetings don’t

happen without you being present.


Keep a Chron: Yes, unfortunately, you may have to get to the point where you keep

a chronological timeline of what has happened over

the duration of the project. It’s extremely sad when it

comes to this point, but I’ve worked with internal

resources and client resources in the past that

necessitate this level of documentation. The goal of

the chron is not to bring it out and beat someone

over the head with it, although that sometimes is

necessary. Ideally, the purpose of the chron will be able to help you refresh your

memory as to the order of the events that have taken place and who said what and

when they said it. You can use your IT planning software to capture small notes and

details along the way that will help pull such a file together if need be. When the

smoke screen begins to emerge you can bring this document along with you and use

it as a fan.

Call Them Out on Their Smoke Screen Ways: It may be that the same person does

the same thing in putting up a smoke screen time and time again. You may just have

to call them out on this fact and ask them not to do this anymore. We’re not talking

about publicly embarrassing them in front of their colleagues and superiors. Rather,

you can take this conversation off-line. The conversation can go something like

this…“Look, over the past couple of projects you seemed to have trouble finishing up

some activities. I’ve noticed a tendency to blame it on something else that really isn’t

the problem at all. First of all, I’d like to ask you to stop doing that because it

introduced a lot of unnecessary confusion to everyone else, and second, is there

anything I can do to help you keep up with your current tasks?”The example above is

a non-threatening, “what can I do to help” conversation that will end with positive

results, especially if the person is a good resource. Otherwise, it puts them on notice

that you know what they are up to and aren’t going

to put up with that type of behavior on your project.

We know we don’t work with any super villains these

days. But, in those instances where a good resource or

two has the urge to throw up a smoke screen to try and

get away you now have a Bat Fan that will blow the

smoke out of the room and uncover the truth!

http://www.projectmanager.com/resources/wp-content/uploads/2012/12/sinking-ship.jpg



The Top 10 Project Software Development Mistakes

We’re going to offer up our Top 10 List today, a countdown of top Project Software

Development Mistakes. They aren’t terribly funny but undoubtedly will resonate if

you’ve been managing software development projects for any length of time. So, in the

spirit of Late Show with David Letterman let’s start with number 10 and work our way

up to number 1.

#10 – Sinking the Ship with Too Much Process

Putting so much process around a project that it sinks the ship is common mistake in

project software development.

One line of reasoning says that if a little bit of process helps things go smoothly, a lot of

process will make things go even more smoothly. This is flawed thinking. When there is

too much process, everyone is more focused on following process than on actually

getting work done.

Checkpoints, forms, approvals, documentation, and other processes are necessary;

however, don’t allow them to become a burden and counterproductive. A good rule of

thumb is to put just enough process in place to float the boat. Once the boat floats,

move onto another area to improve. Don’t sink the ship!

#9 – Not Accounting for Ramp-Up Time

There is an assumption that if you put an experienced, skilled, and talented developer

on a new project he’ll hit the ground running. This is especially true if the person has

been with the company for some time and knows what they are doing.

However, it’s a project software development mistake to expect this person to go from

0 to 60. You need to factor in time for this person to get up to speed no matter how

experienced they are, and include even more time if the person is new to the

organization.

#8 – Not Including Administrative Tasks

At number eight in project software development mistakes is not including enough time

(or any time, for that matter) for administrative tasks. Think about what a team

member’s day is filled with: meetings, phone calls, interruptions, filling out time sheets

and clearing out email inboxes.


All of these activities have one thing in common…they take time. If time for

administrative tasks isn’t allocated in their schedules it will negatively impact your

project plan at some point.

#7 – Expecting Resources to Work on Too Many Projects

Another common project software development mistake is expecting your resources to

work on multiple projects at the same time. This usually happens to the more capable

resources on your team.

For example, a new project comes in with a complex problem, and you need someone

to jump on it quickly and provide a recommendation for a solution; you assign your best

team member to the task. Meanwhile, another project comes in; some of the other

resources are getting behind so once again, you ask your best team member to help.

You see the pattern developing here? Before long, the performance of your best

resource is at risk because they are overloaded. Spread the work out, train others, and

keep your best resources focused on their projects.

#6 – Your Time Horizon is too Long

Sometimes it’s hard to know what you will be doing tomorrow, let alone three months

from now. The same applies to members of your project team.

It’s a project software development mistake to plan out inordinately long periods of

time in great detail for a number of reasons. First, it takes an extraordinary amount of

time to create detailed project plans…that

will most likely change. Second, it frustrates

developers when continual changes prevent

them from sticking to the original plan.

Finally, you don’t even know if the project

you are working on will remain in its present

form three months from now.

It’s okay to plan the immediate future out in

great detail, but stick to higher levels of

planning further out from where you are

today.



#5 – Throwing Bodies at the Schedule Will Catch it up

It is a classic project software development mistake to think you only have to throw

people at a problem for it to take care of itself. Warren Buffet expressed the sentiment

this way: “You can’t make a baby in one month by getting nine women pregnant.”

There are certain things in life that take a specified amount of time no matter how

creative you get. Throwing extra people at a problem on a project may introduce more

confusion and cause even more delays.

#4 – Expecting 100% Full Utilization

How many hours does a full-time person have available in a year? According to my

math, 40 hours times 52 weeks equals 2,080 hours.

You are seriously deluding yourself if you felt you could even get close to that amount of

billable or productive hours from your resources. Generous vacation schedules and paid

time off policies all take a chunk of time out of those theoretically available hours. Plus,

it’s the rare worker that doesn’t take a sick day every now and then.

Couple this with the time that is devoted to administrative tasks from #3 above and you

may find yourself in the range of 60%- 70% utilization. That’s if you are fortunate. Basing

your plan on a higher utilization percentage can seriously throw your project off track.

#3 – Not Including Contingency Plans

Another downfall of many software

project development plans is to not have a

backup plan. The assumption is that

everything will go exactly to plan, but you

only need have managed a couple of failed

projects to realize this is the farthest thing

from the truth.

Resources quit, management shifts, and

direction changes. You need to have contingency plans in place to deal with each of

these ‘known unknowns’ in addition to the ‘unknown unknowns’ that you haven’t even

contemplated yet. Make sure you have a Plan B for everything that you know could go

wrong. In addition, it would be good to include a placeholder of time to accommodate

those unexpected events.



#2 – Not Checking in Frequently Enough

Everyone gets busy and loses track of where things stand from time to time, but it’s

important to not let that amount of time get out of control. It is disastrous for project

software development to go unchecked for weeks or months. Projects should never be

allowed to go on auto-pilot because they quickly can veer off track.

#1 – Thinking “It’s on the Critical Path” Is a Motivator

The number one project software development mistake is expecting people to work

harder when you say, “It’s on the critical path.” It’s an expression that has been used for

generations to stop resources dead in their tracks and get them to say, “Okay. I’ll stop

all the other items that are on critical paths as well and jump right on this one.”

That’s the problem—everything everyone works on these days is on the critical path.

You need to come up with different forms of motivation to gain buy-in and keep people

engaged in their projects.

There you have it, my top 10 project software development mistakes. Do what you can

to avoid these mistakes and your projects will go much more smoothly.


30 Day Free Software Trial

There are two key differences between ProjectManager.com and its competitors.

The first is that we give you all of the features you need to plan, track and report on

projects efficiently. The second key difference is that our competitors charge a high

upfront price as well as annual maintenance fees for new releases.

Here at ProjectManager.com we offer you all of the features you need to manage

projects, at a small monthly price of just $25 per user. That simple! When you sign up to

ProjectManager.com, you also get for free:

Unlimited Projects

3 Gigs of Document Storage

Client Login

Free Upgrade to New Releases

Take Action, Sign-Up for a 30 Day Free Trial Today!

Take a Free Trial

Create your own Projects

Sign up to boost your project success

Any questions? Email [email protected] and

one of our friendly support staff will be happy to help. We

also recommend a visit our resource library if you would

like access to further:-

project management tips

video tutorials

project management templates

https://secure.projectmanager.com/free-trial.aspx

https://secure.projectmanager.com/online-software-signup.aspx

mailto:[email protected]

http://www.projectmanager.com/project-manager-blog

http://www.projectmanager.com/project-management-training

http://www.projectmanager.com/project-management-templates

Date post:	08-Nov-2014
Category:	Documents
Upload:	jason-westland
View:	35 times
Download:	0 times

The Best of IT Project Management

Documents