Top Two Factors That Tank Many IT Projects

Top Two Factors That Tank Many IT Projects
By Sean Kenney

I have been dealing with IT projects for the last 15 years of my career. There are many things that contribute to projects that are both successful and unsuccessful. I have had a post-mortem on many projects and it always seems to come down to a handful of things that sets the pendulum one way or the other.

Team Motivation

Ensuring that your team is motivated to work on your IT project can be a daunting task. Who really does want to get excited about creating yet another web application that has the ubiquitous n-tier architecture with the usual database backend? Well not many people that I know do.

One way to get around having a team that is not motivated is to ensure that the team dynamics are good. What does that mean?

The better you team works together, the more they typically get done. It is funny how developers want to do more when they can enjoy the team they are working with. I have been in scenarios where there were “bad eggs” in the team, and it just brought the whole idea of building momentum to a screeching halt when the “egg” entered the room. Once the egg left, people were back to developing, talking and building the solution again. The end result is that no developer has ever been worth the team/project that I have been on. Ever.

Even outings as simple as going to lunch or the occasional after-work event keeps teams in good spirits and willing to go the extra mile, if needed.

Let me be clear. I am not advocating using lunches and after-work events to suck another 20 hours a week out of your employees. That is bad in both the short-term and long-term.

Technology

As an architect, I know that technology obviously plays a major role in most IT projects. I also understand that there are some situations that you are thrown into, where you cannot change whatever bad decisions were made up to that point. However, you can make sure that the technology decisions that are made after you arrive can prove that you understand the problem and are driving towards the best possible solution.

What really bothers me is that I have come across many projects where the technology was chosen simply because it was:

• Cool ( the worst offender)
• New (this is almost as bad)
• Complicated (this is always the fun one)

I know that no one reading this article would ever choose technology for the reasons above. However it does happen and there are ways to avoid in in the future.

Never choose a technology that you don’t understand.

I am not saying that you have to be an expert in any technology that you look at as a potential solution. What I am saying is that you need to do your research. Look at the technology to ensure that it solves the problem area that you are looking at.

I would recommend a SWOT analysis as a starting point. If you find that it meets your needs from the analysis standpoint, do a prototype. The prototype needs to ensure that you have covered major areas of functionality and that the technology can handle your specific business problems. When I do prototypes, I don’t do them to prove that the technology can be used; I use it to prove that the technology should be used.

Once you finished a prototype, you can demonstrate with facts that the solution chosen was in fact the correct one.

Never choose a technology that only you understand.

There are other people on this planet and eventually you will have to transition your solution to someone else. Having a solution in a technology that only you can understand will not guarantee job security.

I have been in a couple of different scenarios where there was a team member who did everything as complicated as he could possibly make it. That was great for his ego, but he typically took longer than most to do the work. He also typically made the solution quite brittle as it very tightly coupled due to the complexity.

When this person left, it took a bunch of team members a while to understand the code and the intent of the code. It also took a fair amount of time to refactor the code to ensure new team members did not take the same initial ramp time as the previous team members.

Overall – Bad idea to make code really complicated, unless:

• The code will never change, and
• You have encapsulated into a file that will never need to change.

I am 99% sure one of those will never be true.

Sean Kenney is a software architect in Houstan, Texas. You can read more from Sean on his blog.