How to manage a project without deep knowledge in all the technology involved? [closed]

Question

In my organization we have to handle multiple projects with different technologies,like flex, iphone, .net, php etc. The problem is I know only java.

So if a developer says me that an issue will take 2 days to solve I really cant judge whether he is right or wrong.

How to handle this situation?

One more problem is that because I don't know a particular technology so its very tough for me to say that whether a particular thing is possible or not in that technology?

I prepare project plan, documents, contact with clients these things but have almost no controls on developers because my insufficient knowledge of all those technologies

What can I do about this?

Answer 1

If an estimate strikes you as a bit over the top, surely the developers should be able to explain what it is that will cause the delay. Especially if you know java - they should be able to explain it to a non-tech project manager as well (after all, the project manager might be required to explain to the customer).

Other than that; trust your developers. They probably don't underestimate badly enough to get you into a tight spot, but you should always give yourself some margin as well, when communicating with the customer. If they constantly over-estimate, you should notice that after a while.

Answer 2

This is from Scrum but it is applicable even if you don't do Scrum. In Scrum, only the developer is allowed to give an estimate of how long it would take to do something. Managers are not allowed to give, recommend or in any way modify that estimate. So first of all trust that estimate.

But.. most programmers are inherently over-confident. If a programmer says 2 days then it may take him 3 days to complete a task. The estimate does not reflect reality (at first).

The solution to this is to keep a record of the estimate. I usually write the task and estimate down on a piece of card and post it on a big whiteboard. If the task takes longer than the estimate then tactfully remind the developer and make a mental note. Next time, before making a new estimate drop subtle (or not so subtle) hints about missed deadlines or early completion. This way the developers will slowly learn to improve their estimates.

Be cordial in all this. The aim is to get accurate, reliable estimates - not to put pressure on people. The whole point of this is to train people to make better estimates. Trust me, having an accurate estimate is more important than missing a deadline. It is relatively easy to tell a client that a project will be delayed by 1 week if by the end of that week you can actually deliver the project. On the other hand repeatedly telling the client that the project will be completed "tomorrow" will quickly make the client lose trust in you.

A few other notes:

When I started this process it took around one month for most people to actually be able to give me accurate estimates. It's not that they were intentionally lying about previous estimates. It's just that people, especially programmers, don't actually know how to make good estimates without training.

Whenever developers come up with an estimate of more than 3 days I automatically ask them to break the task to smaller subtasks such that each subtask takes only 1 or 2 days to complete. This also automatically generates milestones that you can actually track to see if the task is going well or is stuck.

Explain this process to your boss and get his support. It is very hard (but not totally impossible) to do this if your boss keeps pressuring you because you will end up pressuring your developers. Your boss must understand that time estimates can only be made by people actually spending time doing the job.

Answer 3

you should probably trust your developer's estimates, yet expect that they won't always be 100% accurate, remember they are estimates. It might also be a good idea to use a process that has the acceptance built in that estimates are only estimates, and either doesn't require them (e.g. Kanban), or has features built in to adapt to the nature of estimates (e.g. Scrum).

PMs shouldn't really need to know that much about the technology, as that is what the developers are for, but I understand that is not always the case, particularly where the PM also has technical responsibilities.

So judging whether or not something is possible shouldn't be your responsibility alone, this type of evaluation should be delegated practically completely to the developers, at least regarding the technical considerations. You can still provide your evaluation where business, economic, and customer considerations reflect on the possibility or otherwise of some endeavor.

In short, leverage the developer's technical knowledge where it is needed.

Answer 4

Befriend your development team. Explain that your job is not to boss them around or tell them how to do something and how long it should take, but to help them co-ordinate and shield them from direct interaction with the clients.

Once you are in a situation of mutual trust, describe the needs of the client and rely on the estimates provided by your developers. They're the ones who have the knowledge anyway.

Should a client ask you for an estimate on the spot, answer that it's impossible to give an exact figure without putting some thought and expertise into it. If they insist, answer a large-ish figure (at least what it would take you to do that same thing in a language you know) and tell them that you will provide the actual numbers shortly.