Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Recently, we have hired bunch of people who say they have little experience on technology. When I delegate jobs to them and ask for a timeline, they give unrealistic timelines of around 3-5 months.
I think the tasks should actually take only 3 weeks to 1 month. The client can't wait for prolonged periods!
What are the ways I can help team members to get projects done within the client's expected time frame?
Targets and estimates are two different things. You're confusing the two, and setting your team up for failure.
A target is something you assign to your team, such as "I want this set of tasks done in a month." Management targets are fine so far as they go, but they rarely provide a means to get there. For the actual accomplishment of the tasks, you need to rely on the knowledge, skills, and experience of your team.
Estimates, on the other hand, are what your team provides based on their current understanding of the problem domain and their assessment of their own skills. A skilled person might be able to add a feature or solve a problem faster than someone with less experience. On the other hand, sometimes experience leads to insights about how seemingly-simple tasks might take longer than expected. Either way, the estimates are generally good guidelines for how long the actual task-performers think the job will take.
Right now, your team is estimating that the project will take three to five months, while your management target is a month or less. Neither side is necessarily wrong; however, there's clearly a discrepancy between targets and estimates that needs to be resolved.
What are the ways I can help team members to get project done within time?
This is the wrong question. What you're really asking is how you can get your team to deliver what you want when you want it, rather than when they think they can give it to you.
If you know how to get the tasks done faster, share your knowledge. This will probably entail you being a hands-on participant on the team. You may even have to take ownership of various tasks yourself, since you may be able to get things done faster than the other team members.
Then again, maybe not. Maybe the team is right about the fact that, with the resources you have and the experience level of the team, it will take longer than you'd like for the team to deliver on the project's milestones. If so, unless you plan to do all the work yourself and have factored that into your scheduling estimates, you may want to carefully consider whether or not your team is correct.
When a project's leadership is out of step with the members of the team, a good project manager will work with stakeholders and the team members to understand why. Perhaps your team simply lacks confidence, or wants a buffer so that they aren't blamed if things fall behind schedule. Or maybe the project's delivery dates are unreasonable based on the skills of the team or the resources available to the project. Whatever the reason, you won't really get to the bottom of it until there's an honest conversation between management and the rest of the team about the issues and risks.
Recently we have hired bunch of people who says they have little experience on technology. (sic)
Consider the following:
No matter how you look at it, people can only accept responsibility for tasks they've agreed to complete with full knowledge of the details and circumstances. You can certainly assign tasks and deadlines to members of a project team, and then "hold them accountable" for the management targets, but that rarely works well in the real world. You might even get team members who will agree to anything rather than lose their jobs; that will get you a lot of agreement, but rarely will it get you completed deliverables when you expect them.
Management is responsible for gathering accurate estimates, managing the client's expectations, and empowering the team in whatever ways are possible so that the team can do as well as they can, where they are, and with what they have. Failure to do perform those essential management responsibilities is what causes 68% of projects to fail.
Flogging your staff until morale improves rarely works. However, converting your project management process to a framework that values rapid feedback cycles, process transparent, and full visibility into the project's processes and impediments will make sure that:
When you mash all of that together, it's effective two-way communication that may enable your project to succeed despite its shortcomings. Teams that communicate effectively succeed more often, and when they fail they fail earlier and at lower cost to the company. Encourage honest communications at all levels involved in the project; it's really your best tool, so you might as well use it as effectively as you can.
they give unrealistic timelines of around 3-5 months
They give realistic timelines, taking into account their own skills and experience. However, your expectations are unrealistic.
According to PMBOK, there are two main options of "schedule compression":
For example, see this blog post.
There is a lot in your draft that suggests you yourself are lacking some basic fundamentals or understanding of how estimating, targeting, performance, and risk work.
CodeGnome touched on a good bit in this area that you need to read closely and try to understand. The only disagreement I would have is his explanation of target versus estimate, where I would suggest that an estimate is a range of probabilistic results and your target is deterministic, a single value for which you aim, on which you base your costs, and against which you measure your performance. It indeed can be assigned by you but it is the value that represents the degree of risk you are willing to take and lives somewhere in the range provided by your team.
What your customer expects is irrelevant in the estimation process and should not even enter into the equation. In fact, the estimators should be blind to that piece of information as you do not want their opinions biased to it. The estimation process yields the range. The business side of that process chooses the target which may or may not be consistent with what the customer wants. So, if your team says three to five months and you target two to meet customer expectations, you are essentially making a business decision to buy the business at a loss and extreme risk of failure. Nothing wrong that; there are a lot of loss leaders that drive very profitable business down the line. But it's not your estimators job to come up with that.
Finally, you need to understand how performance works. No matter the target, much of the results that you will see over time is very very random. Understand what aleatory risks are and how these affect performance. Aleatory risks, as opposed to epistemic risks, are largely or wholly unreduceable. They are random. You cannot mitigate them. I bring this up to challenge your belief that their risks are "unrealistic." That implies that an estimate is "realistic." You should divorce the word realistic from estimate here on out.
I agree with CodeGnome and would like to add more
Retrospection
Look at what you are doing and how you are running the project and ask yourself a truthful question; "Is it working". I would say no it is not. Next look at ways to do things differently by taking a deep look at what you are doing, then learn from your mistakes and try do something differently.
Insanity is doing the same thing over and over and expecting a different result - Einstein.
Uncertainty and Complexity
Next is to admit you are dealing with software development which if you really look at it has a high level of uncertainty in it. Possibly to do with requirements, teams, people, technologies and thus fraught with risk. As much as you plan, you will more likely than not encounter situations that no one could have predicted. Finally technology is complex and moves at a fast pace; there is always high degrees of complexity in what we do.
Learn to mitigate these risks through empirical processes control instead of procedural process control.
Communication
It appears there is some level of misunderstandings in the requirements, you think it is a month and the dev team thinks it is three ... get in front of a whiteboard and talk it through.
Human Factor
I pretty much bet that right now, you and your team are all making decisions based on the facts you currently have at your disposal. I don't believe that anyone will be deliberately making bad choices. Both of you may be making misinformed choices as not all the facts are transparent and known. Right this very moment, you don't know what you don't know. In a few days you might find out that your thoughts today were completely wrong.
Stop beating up the team based on previous choices everyone has made, respect that the want to do the right thing. Help them do the right thing by constantly communicating and making minor corrections as you find deviations (again inspect and adapt).
