12

I just took over a project from a Project Engineer and just saw a revised project schedule. The revised schedule shows the project will be delayed by 3 months. I am trying to complete it within the old schedule, which would make the project on-time.

How should I review the submitted schedule, and how can I improve it so that I can finish it within the old time frame?

Improve this question
1
  • 1
    There's some good answers, but my first questions is - 'why' is it behind schedule? The advice given so far is great, but it's shooting in the dark. You can't improve it of finish to original schedule unless you first know that answer. THAT will dictate how to correct.
    – Trevor K. Nelson
    Commented Sep 25, 2012 at 0:01

4 Answers 4

Reset to default
10

When you review the schedule, have stakeholders with you and look for those items which have less value in comparison to the other items.

There is a so called "iron triangle" in software development. It talks about money, scope and time. Let me take a quote from Jeff Atwood (co-creator of SO and SE):

These three factors are all related. If you pull on one "edge" of the triangle, the other sides have to give. If we cut the budget in half, we can't do as much, so scope has to give. That's why it's often called the iron triangle.

So, if you would like to move forward, you either reduce the scope or add more money to the project and add more developers. The last idea won't really work, because adding more resource will add more communication and coordination overhead, and the project will take even longer than before (Brooks' Law).

The only thing you can do is wisely check the current situation, check what has been done, what is under development and what is coming, and reduce the scope. You either throw away planned or ongoing features and focus on those which are critical to match your deadline or you move them to the next delivery.

The key here is to have the stakeholders/customers and let this scope reduction be a conversation and consensus.

The following suggestions will pop up and your job is to handle them properly (by saying no):

  • More resources: I talked about it before.
  • Additional working hours: This will kill the morale, people will get tired, and people will do mistakes, which will risk the delivery date for sure.
  • Bonus as motivation: This shifts the focus from the delivery to a personal goal - unfortunately, this one is more powerful - and the features will be there for sure, but their quality will be very low.
Improve this answer
1
  • @jmort253 thanks for the corrections!
    – Zsolt
    Commented Sep 24, 2012 at 12:51
6

There is a finite number of things you can do to bring in your schedule. Can you crash it? This means can you throw more labor into it, which, in theory, will bring in your duration as well as explode your costs? Do you have some labor bandwith that will allow you to start packages that are scheduled down the road? This is fast tracking. It may adversely impact your costs. Can you remove some scope? This is called removing scope.

This is very controversial, but can you degrade the quality and call things finished before you may otherwise have? Many would have an issue with this suggestion but I think it is done all the time.

Are there different methods available to you for the work? For example, if your method is to move five tons of dirt with five laborers, five shovels, and some wheel barrels, several backhoes and dump trucks may speed things up. (You'll have to translate this to the type of work you're doing, of course.)

If none of these things are possible, then re-estimate the work again and see how aggressive you care to be on the probabilistic distribution your time estimate and publish a new schedule.

Improve this answer
1
  • +1 - I really like how you defined terms in the first paragraph, which helps future visitors, those who are just getting started, in understanding the important terms.
    – jmort253
    Commented Sep 23, 2012 at 2:11
2

If tihe methodology is poor or non-existent, you should be able to reduce development time by improving the methodology being used.

If code reuse is bad, you may be able to decrease development time by improving either. Repeated code is much more more expensive to maintain (even during development) and highly fragile (often one copy gets missed in the patching). Identifying and refactoring reused code when a bug is being repaired limits the overhead for existing code, and quickly gets you to one copy of problematic repeated code.

Using existing frameworks and libraries rather than developing the functionality in-house can also decrease development time. This can reduce both development and testing time.

Adding resources can be counter productive. I managed one project where additional developers were imposed in attempt to meet a deadline. This was highly unproductive as new developers weren't productive, and existing developers ended up spending a lot of time helping them instead of developing. The new developers were quickly assigned to other projects.

As other have noted, all other things being equal you are stuck with the iron triangle. Consider these options:

  • develop the minimal usable system by the original schedule (reduce scope).
  • remove or reassign the least productive team members. (Reduce/reassign costs.) This reduces communications overhead and may speed up development.
  • buy part of the solution. (Increase cost.) Frameworks and libraries mentioned above count.
  • overtime or time shifting (Increase cost.) Getting some key components developed at the right time may pay off. Regular overtime tends to be counter-productive so don't rely on it.
  • identify and remove blockers. (Increase immediate cost.) The best project managers I have worked with ensured solutions were provided as soon as possible. Identifying and removing future blockers helps even more.
  • add appropriate tools. (Increase cost.). I am constantly amazed that managers don't invest in productivity enhancing tools.
  • add a wiki, or other communication tool. This can improve communication and consistency across the project. It can take some work to convince all the team members that the wiki documentation belongs to the project and not the author. Everyone should feel free to update the project documentation there. '
Improve this answer
0

When I have to take over a project and I need to review or improve the schedule, I follow the same steps I follow when I have to create a schedule from scratch.

From my experience, the 6 first steps are:

  1. Open the latest version of you work breakdown structure to outline the schedule
  2. Ask to your team what needs to be done to deliver what is in the work breakdown structure
  3. Identify with your team in which sequence they suggest to do the activities
  4. Get to know what the team need to work on the tasks to deliver what is in your scope
  5. Get the first estimations of the effort and duration
  6. Consolidate all the information in the project management tool you will use to manage the project schedule

In my article “6 steps for creating a project schedule”, I write also about what happen after you follow these steps and things to keep in mind to create great project schedules.

I hope this helps!

Cheers,

Falcon

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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