How to manage a project without deep knowledge in all the technology involved? [closed]
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this questionIn my organization we have to handle multiple projects with different te开发者_StackOverflow中文版chnologies,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?
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.
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.
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.
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.
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:
- Better estimates
- Sets more accurate expectations with both client and dev team
- 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.
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.. )
The only way to get an accurate estimate is to break the task down into small units of work. The smaller and more focused the units of work, the more accurate the task estimate.
Getting the team together to discuss exactly what each task will involve is a great way to peer-review the proposed technical solution. Often a better technical solution is hatched by the team through detailed discussion of the task. This is a great use of time, and you'll easily recover the design-peer-review time once development starts.
If you sit in on these team discussions then you will start to understand the technology a bit better, and you will start to trust your programmers more as you understand the estimating challenges from their perspective. It is also a great way to cross-train the team, as you'll often hear the phrase "I didn't know you could do that" as developers share their knowledge. Make sure the team reviews are ego-free and friendly.
加载中,请稍侯......
精彩评论