How to tell your boss his team lead choice is not the best for the project?

Question

basically I'm working on project X. I joined my company 1 year and a half ago and started working on that project under the lead of developer Bob, Bob is extremely professional and has the skills to lead the project in the right spot.

After some time (2 months) Bob began to work on another project due to the fact my skills were enough to lead the project without him and managing the team, so basically i was promoted to TeamLeader of that project so Bob could work on other projects .

Now, after 1 year of lead, the project ended in such a good way that the client asked us another big evolutive (like 1 year of development), and my boss said that Bob is going to take the lead of the project.

Note that I know that Bob is more skilled than me,I'm well aware that he can lead the project , and I don't have any problem on working under him on other projects.

I am just sure that Bob, who is unaware of how the project went on this WHOLE YEAR of development, should spend like 2/3 weeks on just studying the way the project works now,and then going back in the code and understand how it works.

I'm pretty sure he is capable of doing it, I just think this is a waste of time, assuming I'm still capable of going on alone in this project.

How can I prompt this to my boss? should I do it?

EDIT: My company is +400 people

Answer 1

Are you sure you are the right person? From your description it seems like you took over 'team lead' on your current project after Bob had already gotten the project rolling. Managing a project that's in-progress is very different from getting a new project started.

While a project is in development you are managing 'mostly' already defined task lists. You are executing the previously performed preparatory work and planning. In other words, you have all the to-dos, materials, tools, budget and staff, now it is a matter working off the list of tasks and ticking the checklist.

Managing/leading a new project usually requires a lot more knowledge/experience. I don't want to under value the importance of having a good team leader throughout a project, but the skills involved once everyone is off and running are far less (or maybe 'far different' is a better phrasing) than the skills involved in ensuring the project is setup to be successful.

Just a few bullet points for illustration (there are many more)

• You have to make decisions about things that haven't been defined yet. That even includes identifying those things that still need to be defined. One example would be deciding how you are going to test the product to prove it meets the requirements. Since you don't have a test plan yet, you've got to make decisions on what you believe will be in the test plan in order to make sure you are able to test the product when you planned to test it. After all, there may be things that need to be ordered or built.
• You need to make sure you identify everything that will be needed to complete the project and ensure it will be available when needed. Many of those things most developers never think of because it's 'just there'. A few of many examples includes things like tools, 3rd party library licenses, 3rd party software applications, hardware, simulators, operating systems, development environment....Discovering that you need a piece of hardware to complete the project and discovering that the hardware has a 3 month lead-time, but only discovering this when you actually need the hardware can be a disaster.
• You need to make good buy or build decisions? That library might cost $20K so you choose to build. Not a good plan if it costs $50K to build and test in-house.
• Schedule and Staffing. Most projects have limited budgets and most companies have a limited number of staff. Creating a schedule is a challenge in its own right. Creating a schedule that semi-realistically shows you can meet the due dates, within the budget and only use the limited number of staff available is a monumental task. Odds are that you aren't going to be able to have the 10 full-time developers for the entire project like you desire, you'll have to plan accordingly.
• Identifying vague requirements, helping in negotiating the details and coming up with desirable alternatives/interpretations with the customer is very important. It takes experience to know which of these innocent and easy sounding requirements could end up turning into months of development work. It takes skill to convince the customer that some 'safer alternative' is better while at the same time not having the customer feel like they aren't getting everything they want.

I could go on with additional bullet points, but you should get the point by now.

It seems like you've demonstrated yourself to be a good development lead, but don't underestimate the large number of skills required to getting a new project on the proper trajectory to becoming a successful project. One thing that might be unexpected is that those 'large number of skills' tend to be very different based on which company a person works at and even the project itself. Even experienced team leaders that are new to a company may not be qualified to be the 'team lead' of a new project until they learn 'the company way' of doing things.

Instead of telling your manager that you think Bob is the wrong person, maybe you should request that you be able to get involved with Bob on working on all those startup planning details. That way your boss will know that you've been through the startup process and may consider you next time.

Answer 2

I think you are really looking for an opportunity to continue to lead the project and prove your worth. There is nothing wrong in having this as an ambition for your career.

You just need to present to the management what it is and convince them that you are capable of leading it on your own as you did last year.

However, there is no need to bring Bob into picture and present him as "not the best choice". You accept he is more skilled and he is capable of leading the project. 2-3 weeks of catching up time should not be a big deal and you (probably) know that too and I do not think management will be convinced by that argument.

Answer 3

Are you unhappy with Bob leading the project, or with your manager's decision that Bob should lead the project? The two things are very different.

First one means you have legitimate concerns about Bob's ability to perform as well as current management (you).

Second one means you don't trust your boss's judgement.

First one can be addressed in a risk management meeting with Bob, your manager and yourself, where you could point out all risks you perceive, weight them and try to mitigate them in some way (Bob could take a break from his current project and do peer review on your code with you, you could refactor parts of the code that are ambiguous etc)

Second one is difficult to manage as it's a matter of trust. You could try talking to your manager about it and straight out tell him you don't trust his judgement because x and y reasons, but that rarely ends well in my experience.