Having the Correct People on a Project Is Key to Success

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
Parents
  • On almost every project I have been assigned to, the wrong people were working on it. Sometimes I was one of those wrong people. Every time there were people perfect for the project that were "needed elsewhere" or "not appropriate for this assignment." Like the routing expert who couldn't participate in the project rewriting routing tables because he was needed on a database project so we worked with the DBA on our project. Or the guy who contributed to BIND in his off hours not being included on the project to implement IP telephones so the DNS expert can learn how to create custom DHCP options.

    The worst was when a desktop support guy was assigned to create the new network on a school campus. Instead of the hub and spoke approach from the MDF to the various IDFs, he didn't see an issue with a linear backbone connecting all the switches in a daisy chain. The servers were at one end and the MCC at the other end, so someone in the district office (in one building on the campus) would have their traffic to and from the file server bounce through five unnecesary hops in each direction. Even more fun, since he didn't have a spool of coax, he used thinnet! When I was asked to troubleshoot the network because of poor performance, I found the coax, had it pulled through (the longest hop was only 60 m), created the hub and spoke topology we are all familiar with, and moved the servers to the central closet. People were amazed at how much faster the network was.

Comment
  • On almost every project I have been assigned to, the wrong people were working on it. Sometimes I was one of those wrong people. Every time there were people perfect for the project that were "needed elsewhere" or "not appropriate for this assignment." Like the routing expert who couldn't participate in the project rewriting routing tables because he was needed on a database project so we worked with the DBA on our project. Or the guy who contributed to BIND in his off hours not being included on the project to implement IP telephones so the DNS expert can learn how to create custom DHCP options.

    The worst was when a desktop support guy was assigned to create the new network on a school campus. Instead of the hub and spoke approach from the MDF to the various IDFs, he didn't see an issue with a linear backbone connecting all the switches in a daisy chain. The servers were at one end and the MCC at the other end, so someone in the district office (in one building on the campus) would have their traffic to and from the file server bounce through five unnecesary hops in each direction. Even more fun, since he didn't have a spool of coax, he used thinnet! When I was asked to troubleshoot the network because of poor performance, I found the coax, had it pulled through (the longest hop was only 60 m), created the hub and spoke topology we are all familiar with, and moved the servers to the central closet. People were amazed at how much faster the network was.

Children
No Data
Thwack - Symbolize TM, R, and C