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?

+4  A: 

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.

David Hedlund
thanks my organisation...step 1 -the PM has to communicate with client to build the project plan...step 2- build the mock ups---step 3--get approval of those two documents from client and management ....step 4-- project far i m quite good but when developer says that i an unable to this task then what should i do? Should I start study behalf of him that how to solve that or what? Pls remeber I have multiple projects in my hand so I am very sort in time...thank you very much for your quick reply
@mendieta: yeah, you should try to avoid solving the problems for your programmers. that's not your place. at least as long as the problem is a *technical* one. i frequently discuss the non-technical aspects of solving certain problems with my PM, that's probably a good thing, but you shouldn't start telling them what code to write. if they're saying they something *can't* be done, or would take extremely long time, while you know it's relatively easy in java, they should definitely be able to explain why their environment is different.
David Hedlund
i can relate if you don't want to be that guy, tho. "Ha! Back in my days we used java, and this was *never* a problem. We didn't *need* closures." remember that one of your strongest advantages will be that you have actually been in that position. you know what it's like to be a developer under a PM. you also know what matters in programming. schedule time for refactoring, your developers will appreciate that, and *you* know better than most PM's that it's an investment. as a developer, i understand the pressures my PM is up against, and don't mind it when he's pushy.
David Hedlund
excellent David...thnx again i think without thinking technically I should advise them that write the issue in this forum or ask another senior developer or go through this book like this...and I was thinking of learning iphone and flex I think I should stop doing that...if i want to learn some techie things I should continiue with Java...that will make myself stronger rather than learning a completely new technology...pls advise
+3  A: 

Hi, 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.

thnx some day ago we faced a problem regarding fetching system information from Adobe AIR...the developer was unable to do what will be my approach? how to tackle this?
@mendieta: have the developer research whether it *is* possible to retrieve the data of interest. if it's possible in other languages, would a separate application to communicate between the two be of interest? are you working with the developers on the AIR end? might they be able to facilitate in any way, perhaps expose the information via an API? if it *really really* can't be done, that's not really your fault, and you should let the client know that. if it'll be expensive, you should let the client know *that*.
David Hedlund
"fetching the system information from Adobe AIR" sounds more like part of a solution than a problem to me. I would see if it is really possible and what effort that entails. I suppose from your point of view you have to trust the developer that it is not possible, and consider finding a different solution to the actual problem, i.e. the customer requirement could perhaps be implemented a different way.In short, I would present the developer, or better yet team, with simple requests for small snippets of customer functionality, WHAT they should do and let the team worry about HOW to do it.
+2  A: 

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.

Victor Nicollet
+4  A: 

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.

It is good you mentioned Scrum. Another thing most Scrum teams do is measure in relative points rather than hours or days, and the team plans according to the "velocity" of points done in the previous sprint. This helps avoid any issues related to under-estimating.

To put it simply, if you don't understand the technology, you should not be managing a project that uses it. Suppose someone asked you to manage the development of an aircraft - do you think you could do that with no knowledge of aeronautics? It never ceases to amaze me that people think they can manage software projects without the slightest clue about software.



Maybe your process could do with some help.. from your comments above i saw:

  • Step 1 -the PM has to communicate with client to build the project plan...
  • Step 2- build the mock ups---
  • Step 3--get approval of those two documents from client and management ....
  • Step 4-- project starts

Where do the developers come in and estimate? If you're asking them at Step 4, it's too late as you've committed to some sort of schedule with your client and management.

To ensure everyone's expectations are correct, take along a trusted developer to Step 1. Before you present a plan just ask the dev; "how long could we build this with a team made up of n of our developers?"

This has a few advantages:

  1. Better estimates
  2. Sets more accurate expectations with both client and dev team
  3. Increase commitment to those estimates from the dev team

1 and 2 should be obvious, but item 3 is important as people rarely like working to estimates set by someone else. While you may not be able to use the whole dev team in your estimating, use a trusted advisor.

Mark Nold

I also do manage some small projects, some COBOL, some MS, mostly java. I only really know java, and my skills need updating too. We use a scope estimating tool, really just an excel sheet with fields the dev fills in to assess the impact. This helps the developers break down the problem into smaller pieces, it forces them to really think through the steps that need to get done and this gives us a more accurate estimate. Whatever helps the developer, helps you. :) And then when we are done we compare the estimate vs actual and baseline it for future references. We define good estimates as having a variance of 10% or less.

Don't just blindly trust the developer's estimates - you don't know where he's basing that from, no one could ever know 100% of the technology/framework or data model or business rules or such. Know what he has factored in the estimates. I believe trust is earned. If a developer has given bad estimates before, would you trust the estimates he'll be submitting next is adequate? I definitely won't, unless I see an improvement.

I've been a developer, and I have made quite a few bad estimates too. (Hhmm maybe that's why I'm less of a developer now and more of a manager.. )