The Best of IT Project Management by Jason Wesltland

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 ProjectManager.com © 2013 All Rights Reserved

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, ProjectManager.com © 2013 All Rights Reserved

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.

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 ProjectManager.com © 2013 All Rights Reserved

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â&#x20AC;&#x2122;s best if the core group of stakeholders on the project meet face-toface. 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. ProjectManager.com ÂŠ 2013 All Rights Reserved

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 upto-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 ProjectManager.com © 2013 All Rights Reserved

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! ProjectManager.com © 2013 All Rights Reserved

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 singlehandedly, 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 ProjectManager.com © 2013 All Rights Reserved

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 midair. 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. ProjectManager.com © 2013 All Rights Reserved

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 ProjectManager.com © 2013 All Rights Reserved

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 ProjectManager.com © 2013 All Rights Reserved

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 ProjectManager.com © 2013 All Rights Reserved

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 ProjectManager.com © 2013 All Rights Reserved

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 ProjectManager.com © 2013 All Rights Reserved



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 ProjectManager.com © 2013 All Rights Reserved

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 ProjectManager.com © 2013 All Rights Reserved

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 ProjectManager.com © 2013 All Rights Reserved

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. ProjectManager.com © 2013 All Rights Reserved

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. ProjectManager.com © 2013 All Rights Reserved

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 ProjectManager.com © 2013 All Rights Reserved

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: ProjectManager.com © 2013 All Rights Reserved



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 ProjectManager.com © 2013 All Rights Reserved

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 ProjectManager.com © 2013 All Rights Reserved



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 ProjectManager.com © 2013 All Rights Reserved

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: 

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 nonofficial 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. ProjectManager.com © 2013 All Rights Reserved

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 ProjectManager.com © 2013 All Rights Reserved



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 ProjectManager.com © 2013 All Rights Reserved



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. ProjectManager.com © 2013 All Rights Reserved

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! ProjectManager.com © 2013 All Rights Reserved

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. ProjectManager.com © 2013 All Rights Reserved

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. ProjectManager.com © 2013 All Rights Reserved

#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. ProjectManager.com © 2013 All Rights Reserved

#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 support@ProjectManager.com 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