What can I do to mitigate the risk presented by moderately skilled developers?

Question

We are about to start a new project which is very serious.

That will be a mobile project, and the target users is the whole population of a country. The client expects more than 1 million downloads in the first month.

The project is in its initial stage of requirements analysis, documentation and planning.

The main threat to the project success is the knowledge base and skills we are going to use in development process. The mobile developers have little experience and which is more important, middle skills. They have successfully accomplished some small projects, but that is not sufficient to engage in such projects. There are the following reasons why we are in this situation.

1. Management is prone to hire many low-skilled and low-paid developers instead of one highly skilled and highly paid.
2. Management believes that we have to give them the possibility to grow by engaging in such projects
3. There is not any senior developer or tech lead to guide them through this process. And for this project too, we do not have any senior mobile developer.

So, there is a significant risk I should anticipate before starting the development. I completely agree with @DavidEspina who says in this answer

Unlike an operations where you may be compelled to "grow" a resource into a higher performer, on a project, you do not have that luxury of time, nor should a customer pay for that growth.

What steps should I undertake in order to be confident in my future project success?

Answer 1

As the PM, you need to make a power grab play; build a case with your management that, as the PM, you need to have the authority to move resources around, including changing them out, in order to increase the likelihood of success. However, accept that fact that you may not get the power you need to really run the project. Many of us are in that very same boat.

Like many other variables that influence project results, this team variable may be one where you have little to no influence to manipulate. Great PMs do not have control over every variable, despite we like to brag like we do. Great PMs, however, will read early signals of project performance degradation and communicate this finding and predictions early and often as well as mitigate where possible.

Part of your staff plan would include the staffing requirements in terms of knowledge, skills, and abilities (KSA) required. The KSAs will also detail the seniority of the resource within that role, e.g., entry, middle, senior, executive, or something like that.

Based on the team you are assigned, analyze what you have with what you need and DOCUMENT the gaps. These gaps are an input to your risk analysis, meaning you and your team will document the threat these gaps are causing, the exposure, and your plan to cope with them.

Communicate this to your management team in a non emotional, factual way and track your risk throughout the life cycle of the project.

Indeed, project doom is NOT imminent. You could end up being very surprised by your team and produce outstanding results, both because your staffing requirements may have been too pessimistic or you had a bit of luck on your side or this mid-level team is inherently talented or a combination of these and other variables. Keep in the back of your mind that experience and grade are weak predictors of performance. One analogy I use is what we see in aviation. We always like the 20,000 hour, gray-haired captain to fly us around, but who do we send to war in those complex fighters, bombers, and transports? The 600 to 800 hour 24-year-old boy and girl wonder...and with great success.

If your project does degrade, you will have this as one of the drivers well documented with evidence of active attempts to mitigate via your risk processes. This makes you a great PM despite a possible project failure. That said, grow thick skin because you will likely still get blamed and scapegoated; this the nature of politics sadly.

Good luck!

Answer 2

Since your team lacks experience, it is very risky to go ahead without a proper person to guide them. It is not an issue to hire low-skilled developers unless and until you have some person to guide them and sufficient time for them to learn and grow their skills.

But it doesn't work that way. The client would have set deadlines for the project, and if you didn't achieve it, you end up losing customer satisfaction. So it is better to convince your management to hire a skilled person and pay him rather than hiring unskilled person and paying less.

You must try to make your management aware about the hidden cost in hiring an unskilled team. You have bear their training cost, time of studying, etc. If the quality of the product which was developed by an unskilled team is not good then you end up redoing all things from the beginning. It is waste of time, cost, and energy. You may be ready to bear it, but will your customer accept it? I am sure not.

So first try to convince your management team, because ultimately you work to make your customer satisfied. If they are not satisfied then what's the point in working? If they are stern about hiring a low-skilled team then at least hire a person to guide them. Else you end up doing nothing and wasting money and losing a customer.

Answer 3

Appoint a lead programmer, someone to make decisions on the architecture level, and implement the majority of the core code. Ideally the lead programmer or a very small core team should design the basic program before taking on more team members, but I guess that it might be difficult to arrange things so in your current situation. In general, if you have got a choice fewer people over a longer time span is usually vastly preferable to more people over a shorter time span, and if you have to take on more people you will want to wait for the project to be ready for them.

Your SE activity looks like you are not a programmer yourself, so rather than trying to assess the programming skills of your team directly you should try to get your team members to assess the skill levels of one another. Try making every come up with a quick basic design plan, and have them all discuss the plans. After that they should as a group have an opinion of who would be the best lead, if you are lucky there is even consensus.

I don't know if this approach will work with Armenian work culture, it requires your programmers to exert what might be an uncomfortable level of honesty.

Answer 4

What I usually do with critical projects is to get the basics done as soon as possible, usually using some form of incremental project management (e.g. spiral model), however I am not that guy that sticks blindly to a concept, so this is just as an idea.

The concept behind it is to have something "potentially" releasable as soon as possible to:

• Give you and the team the necessary confidence that in worst case, there is something that you could ship. Do not underestimate team-confidence!
• You can identify issues at the earliest moment, and...
• You can plan ahead and i.E. schedule learning sessions for critical parts where your developers have missing knowledge. Or adjust the team if it is necessary.
• You can get the whole chain (plan->implement->QA->client verification) running right from the start, so you won't get surprise issues 2 days before release.
• Team members have enough time to understand the whole setting and requirements as they can see the entire process and the actual use-case as working example. This often leads to improvements/solutions you wouldn't have expected or seen in a pre-planning model as it indirectly involves the experts into the planning phases. Make sure you listen to them and give them room to speak their minds.

And later once your project accumulates speed, you can easily add features by priority one by one without having to fear that a single feature was either missing, not as requested, not worth the time or not fitting into the whole when combining.

Also the client will get exactly what he wants, as he can comment on the results at a very early point. And you can later after release use the argument, that the client had lots of time to intervene or correct features should he still complain afterwards.

Answer 5

The best way to make your case to management is to use metrics. As suggested by @David, I would document the risks and start monitoring them. Once the risk probability starts raising and starts affecting the timeline (ensure to identify at the earliest stage), take these numbers to the senior management and try to convince them.

Maybe you are better off hiring a consultant to lead the team for the project duration (rather than hiring for a permanent position).

Answer 6

If you don't already have a code review process, put one in place. Every piece of code checked into source control should be reviewed for approval/rejection by at least one other developer.