All too often, companies put the wrong people on projects, and all too often, the wrong people are involved with the project. We see projects where the people making key decisions lack a basic understanding of the technology involved. I’ve been involved with hundreds of projects in which key decisions for the technology portions are made by well-meaning people who have no understanding of what they are trying to approve.

 

For example, back in 2001 or 2002, a business manager read that XML was the new thing to use to build applications. He decided his department's new knowledge base must be built as a single XML document so it could be searched with the XML language. Everyone in the room sat dumbfounded, and we then spent hours trying to talk him out of his crazy idea.

 

I’ve worked on numerous projects where the business decided to buy some piece of software, and the day the vendor showed up to do the install was the day we found out about the project. The hardware we were supposed to have racked and configured wasn't there; nor were the crazy uptime requirements the software was supposed to have; not to mention the software licenses required to run the solutions were never discussed with those of us in IT.

 

If the technology pros had been involved in the process from the early stages of these projects, the inherent problems could have been surfaced much earlier, and led to those issues being mitigated before the go-live date. Typically, when dealing with issues like these, everyone on the project is annoyed, and that’s no way to make forward progress. The business is mad at IT because IT didn’t deliver what the vendor needed. IT is mad at the business because they found out they needed to provide a solution too late to ensure smooth installation and service turn-up. The company is mad at the vendor because the vendor didn’t meet the deadline the vendor was supposed to meet. The vendor is mad at the client for not having the servers the business was told they needed.

 

If the business unit had simply brought the IT team into the project earlier—hopefully much earlier—a lot of these problems wouldn’t have happened. Having the right team to solve problems and move projects through the pipeline will make everything easier and successfully complete projects. That’s the entire point: to complete the project successfully. The bonus to completing the project is that people aren’t angry at each other for entirely preventable reasons.

 

Having the right people on projects from the beginning can make all the difference in the world. If people aren’t needed on a project, let them bow out; but let them decide that they don’t need to be involved with the project. Don’t decide for them. By choosing for them, you can introduce risk to the project and end up creating more work for people. After the initial project meetings, put a general notice to the people on the project letting them know they can opt out of the rest of the project if they aren’t needed, but if they’re necessary, let them stay.

 

I know in my career I’ve sat in a lot of meetings for projects, and I’d happily sit in hundreds more to avoid finding out about projects at the last minute. We can make the projects that we work on successful, but only if we work together.

 

Top 3 Considerations to Make Your Project a Success

  • Get the right people on the project as early as possible
  • Let people and departments decide if they are needed on a project; don't decide for them
  • Don't shame people that leave a project because they aren't needed on the project team