0

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?

9

TL;DR

Targets and estimates are two different things. You're confusing the two, and setting your team up for failure.

Targets vs. Estimates

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.

Resolving the Differences Through Dialogue

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.

Management is Responsible

Recently we have hired bunch of people who says they have little experience on technology. (sic)

Consider the following:

  • The managers who hired staff who may not be qualified for the work is management's responsibility.
  • Hiring staff who are qualified but who lack confidence—something that should have shown up in any reasonable interview—is management's responsibility.
  • Promising deadlines to a client before gathering accurate estimates from the task performers is management's responsibility.
  • Fixing the organizational culture that sets up the project team for a death march is management's responsibility.

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.

Visibility and Transparency Make Mediocre Teams More Effective

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:

  1. The team is actively engaged in the process, and has a mechanism for communicating about process roadblocks and resource gaps to managers who are empowered to do something about it.
  2. The management team will have complete visibility into the progress of the project at any point in its timeline.
  3. Risks to the project will be visible (and hopefully self-explanatory) when they are encountered by the team, empowering management to remove or mitigate those risks.
  4. Increased knowledge between the team and management should result in more accurate estimates from the team, and more knowledge placed into the hands of management with which to make sound strategic decisions for the project.

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.

  • 1
    Your description of Target v Estimate rings true with me, and makes a very useful distinction between the two, which I need to bear in mind when dealing with my stakeholders. I have, in the past, had to explain that a manager can reduce the figure in a plan if he wants, but it won't change the amount of work that needs to be done. In effect, his "estimate" (based on gut feel or even just on a desire to achieve a deadline) is not an estimate at all. It is a target, which is a very different thing. – Iain9688 Aug 24 '13 at 11:31
2

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":

  • crashing: hire different people, give them training, etc.
  • fast tracking: do things in parallel

For example, see this blog post.

2

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.

  • Thanks for your constructive post, David. I was using target in the sense of "management target" (read fixed expectations) rather than "planning figure" (read useful plug-in value for planning purposes). I definitely appreciate you posting an alternative point of view, and your expanded coverage of ranges vs. fixed targets. You also addressed this topic well in pm.stackexchange.com/a/4048/4271 and other comments/answers. – Todd A. Jacobs Aug 22 '13 at 20:16
  • Excellent point. You are exactly right the difference between the two. I'll steal those definitions now. :) – David Espina Aug 23 '13 at 11:29
0

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.