IT project management is a very unique animal that requires more flexibility than other industries. Several methodologies have been developed to help provide improved pliability of the process, but even with the new strategies, some of the same challenges continue to come up time and time again. As a project manager (PM) or someone who manages one, you probably have your own list of pitfalls that you seem to experience on every project. Some of those challenges are organizational based, some may be due to the structure of your project team, and others may be based on the personality of those involved in your project.
CIO Magazine posted a great article titled, “15 Ways to Screw Up an IT Project“. The list they present is not comprehensive and it really offers no solutions. So, here are some framework to help you avoid what I feel are the most common and have the biggest possibility of derailing your entire project.
3. Not setting expectations up front. Let’s be honest, this is a problem that comes up across all project management methodologies and all industries. There is not a project that can be successful unless you manage the expectations of stakeholders, customers, or your project team. The article advocates knowing the answer to two questions before any project begins: 1. What are we going to do, and 2. How do we know when we are done?
While the two questions are an over-simplified approach to determining your project scope, key performance indicators (KPI), and outcomes, if you have documented buy-in from the project stakeholders on these two questions, you will drastically improve the probability that your project will be accepted by the client and come in under budget. How do you clearly set the expectations? Using the Waterfall Project Management or Agile Project Management methodologies, you must require that your team set parameters and be able to answer the two questions. Even using an Agile PM strategy you should know what you are going to do and define project closure.
Bottom Line: Don’t move forward without buy-in from your stakeholders in the project scope, KPI, and intended outcomes.
5. Overloading team members. I have said this before — as much as project managers like to focus on the process of project implementation, your team is made up of real people. The reality of assigning work packages is that the top performers typically will take on more than they can handle either because they are assigned or they volunteer for tasks. But you have to carefully monitor team members and their workload.
As a project manager, you absolutely have to monitor the workload of your people. If they are missing deadlines for work packages and KPI because they have too much on their plate, you need to get them some help. You may need to bring on an additional team member who has the required skill set to complete tasks. If no such person exists within your organization, consider outsourcing some of the tasks. If neither is an option, you have two choices: unload less skilled tasks from the individual or extend the deadline for assigned work packages. Your last choice is to push out the delivery time frame of the project.
If you work with a project manager (PM), you know everyone wants to work with the PM’s that get stuff done. That will sometimes mean they are given more projects than they can handle in a 50 hour week. If you overload your superstar PM you run the risk of burnout, which will lead to turnover. It isn’t unreasonable to ask a PM to work a 60 hour week, but to ask them to work that much for a prolonged period is problematic. You either need to hire another PM or decrease the number of open projects you have. The risk is you will lose your superstar and then have to go through the process of hiring someone else. Not a good strategy.
Bottom Line: Monitor the workload of team members and realize nobody is a robot.
6. Waiting or not wanting to share information. This hurdle is often the product of Waterfall PM and Critical Chain Project Management (CCPM). The framework of this style will delay the rollout of the product of the project until late in the process. There is little excuse in my book for not involving your client — be it an internal or external customer — in periodic testing. In my experience I have found that including them at key points in the design process helps craft a better product that is more likely to be accepted in the end.
I also think that it is problematic to not share information with internal or external stakeholders. This is where the communications plan comes into play. You should have defined what status updates would be sent on what timelines. Stakeholders should have already bought into your communications plan. Status updates should be sent out to the right people and on time. In those cases where a client wants a status update outside of the agreed upon framework, I have found a quick phone call is helpful and saves me time. Most of the time people just want to know what is going on.
If you manage a PM or work on a team with one, know that you should never withhold information from them. If you run into a challenge or a problem, immediately let them know. If you are going to miss a deadline or not be able to deliver on a KPI, tell them. If your PM knows what the problem is, 9 times out of 10 (totally accurate and not made up) they will be able to deal with the issue and help you with a solution.
Bottom Line: Always keep the lines of communication open. Keeping secrets will kill your project.
There are lots of challenges that we face every day as a PM. With 13+ years of experience as a PM, I have seen most of the problems that are identified in the CIO Magazine article and have learned to avoid them through careful planning. IT project managers face a unique set of circumstances, but can apply the lessons learned in other industries to help them become more effective and efficient.