2) "I agree that you should focus on the capability of person. But when an organization is young, most of the people are not smart enough (too little experience). In your article, you used many times the words: smart. Software is not just developed by the smart guys. There are un-smart guys. I'd like to know how to deal with the un-smart guy."
Here are some general rules of thumb about team composition that I like to follow:
Generalist first, specialists last
You should avoid specialists if you can. They tend to be grumpy one-trick-ponies that aren't particularly interested in developing a good core team. Besides, they only do certain tasks, eschewing all other work. Specialists spend a lot of time waiting between tasks that are "appropriate" for their skills, so they are either wasting your project's money OR only partially allocated. Both of these situations add risk and invite failure and can cause tricky scheduling dependencies.
Generalists, on the other hand, can add value throughout the entire project lifecycle. They can help at all phases, which means scheduling isn't such a big deal. In fact, having a team staffed entirely with generalists can go a long way to eliminating dependencies on your projects critical path.
A full-time newby is worth two part-time pros
Don't take on part-time team members unless you absolutely have to. I would take a full-time college grad over two part-time seasoned veterans any day. Part-timers create scheduling nightmares, plus they don't have a sink-or-swim commitment to your project. Both of these things can sink you.
If you have to use part-timers, agree on when they will spend time on your project upfront. If they are 50%, then agree to a schedule, such as Joe Parttime will work on my project all day Tuesday, Thursday, and before lunch on Friday, barring a life-or-death emergency.
Too many cooks will spoil the soup
Some IT people are very competitive, and they can have a tendency to argue endlessly about technical details of little significance. It can be a lot easier to manage a project if there are only one or two highly skilled generalists on a small team. Anyone who can contribute should be allowed to, but you can avoid a lot of fighting if you have one team member who is recognized as the technical leader by the project team (not designated as such by management).
Small classrooms are better
Don't overwhelm your best generalists. Most likely, they have broad responsibilities across the project. You will suck the life out of a single highly skilled generalist if she is responsible for bringing more than two or three (at the most) newbies from dependency to self-sufficiency on your project.
It takes two smart team members just to compensate for one dummy
Being "un-smart," as you put it, and being inexperienced are not the same thing. Smart people will overcome inexperience very rapidly and will be able to focus on developing their own ability to do their work with minimal supervision. Beware the true dummy, though. He or she can be found at any experience level and will be a big barrier to progress, either by their own incompetence or by their tendency to look effective by delegating their work to others and then taking credit. They are extremely costly. Getting a dummy like this OFF your team will have the net effect of adding to people to your team.
This was first published in November 2007