Showing results for 
Search instead for 
Did you mean: 
Create Post

Having the Correct People on a Project Is Key to Success

Level 9

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
Level 14

Too right.  My first inkling of a project was when the supplier turned up with the project manager and said they were there to install stuff.  Apparently the project manager had brought in some mates to do a Cloud Readiness Awareness Project (yep he hadn't spotted the acronym).  He had spent £250,000 and all they were going to do was evaluate our systems to see which were suitable for the cloud.  The problem was that they were all already in the cloud.  I didn't tell them that and then ridiculed the end report when it pointed out which systems weren't cloud ready (yep the ones that were quite happily running in the cloud).

Do you think the project manager learned from this.  NO.  He then bought in some software to help with GDPR.  It provided less information than Netwrix which we were already running.  Eventually they sacked him but not until after all the good technical people had left.  Pity because I had just got Solarwinds up and running properly before I left.  New place has Nagios (but will be Solarwinds soon because I am pushing for it).

Level 14

Thanks for the article!  Lots of good info!


Good points...but one more to add.

Have the right project manager on the project.  They need a good understanding of the environment, people, processes, and standards in play.

Level 12

Reading the solution seems like common sense and you know what they say, "Common sense is not so common."

Level 20

There's no substitute for good people on the team period.

Level 15

If you need help contact me.

I thinked only Brazilian people not right work sametimes.

One might also interpret the title of this section to be equal to


Now define "wrong" without stepping on toes . . .


Level 12

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.


Sometimes when you are working with non-technical team members it can be fruitful to really sell the project as an evangelist would. If people see you enthused they get enthused too. Sometimes it backfires and they just think you are a weird obsessive. As you say though, if you have people that want a project to work, are "onboard", know how to work in an agile fashion... in terms of keeping updated then things work well.

Level 13

Nailed it.  Great post mrdenny . Technical problems are not what will bite you, it's people problems.  There is a principle in  "Good to Great" that really illustrates this - get the right people on the bus, the wrong people off the bus, and make sure the right people are sitting in the right seats.  If you haven't done that, you will almost certainly fail.


Nice write up.

Level 13

Thanks for the article