Jump to content
  • Advertisement
Sign in to follow this  
BlackWind

What to do when the project is delayed?

This topic is 2220 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

This question is what to do / talk with your team members when the project is delayed due to constant delays on the development of the planned tasks?

We are using scrum, and we are estimating times for sprints. Short tasks, short sprints.

But developing the tasks are taking far more time than the original estimated time. We have only been 6 weeks in production and the project has already "2 weeks late". The problem is only with the progamming department. Art and Design is going very well.

What should we do?
What tips / recommendations do you have?

Thank you in advance.

Share this post


Link to post
Share on other sites
Advertisement
Various things which may or may not be applicable:

Make sure goals can actually be accomplished in one sprint; if not, split the task into smaller chunks.
Avoid design changes.
Avoid meetings if everyone knows what they should be doing, or narrow the meeting participation to people who only need to be there.
Have someone see if there are any inefficiencies in day-to-day chores (compile times or other cases where people are waiting for something or someone else before they can continue working). Fix these if possible (you may need to have one or more programmers focus on fixing inefficiencies for a while before gains spread to the rest of the team).
Start cutting features.

Share this post


Link to post
Share on other sites

Hi,

This question is what to do / talk with your team members when the project is delayed due to constant delays on the development of the planned tasks?

We are using scrum, and we are estimating times for sprints. Short tasks, short sprints.

But developing the tasks are taking far more time than the original estimated time. We have only been 6 weeks in production and the project has already "2 weeks late". The problem is only with the progamming department. Art and Design is going very well.

What should we do?
What tips / recommendations do you have?

Thank you in advance.


It sounds as if the project manager is underestimating the time required to implement things or that the programmers aren't doing their job. Don't allocate time on a programming task based on how long it should take unless the task is so simple that there can't be any unexpected problems with it.

If the delays are caused by the programmers not doing their job rather than being caused by unexpected problems (or expected problems that are harder than expected to solve) you need to motivate them or replace them, Nypyren also makes some good points worth looking at. (Allthough i'd say that design changes are inevitable aswell and they are something you should take into account when planning a project)

Share this post


Link to post
Share on other sites
I would have a talk with the programming manager, the chief technical officer, whatever his title is. I'd discuss the problem with him and figure out a plan.

There's an old saw that says when somebody gives you a time estimate, to double it and up it by a time measurement unit. So if he says two days, figure four weeks. If he says one month, figure two years. Clearly that old saw is way off. But if you're two weeks late six weeks in, you know you can add thirty-three percent to any estimated time and reasonably expect to be right, on average.

You also have to play a psychological game here. If everybody knows you're adding 33% to their estimates, they might ease off on the gas pedal to fill the available time. So you might need to find a way to incentivize (bug-free) early completion of a task.

Share this post


Link to post
Share on other sites
Thank you guys.



Don't allocate time on a programming task based on how long it should take


By this you mean do something like Tom Sloper said? (if they say "2 hours" double it and multiply it by some number?) Or how ?




You also have to play a psychological game here. If everybody knows you're adding 33% to their estimates, they might ease off on the gas pedal to fill the available time. So you might need to find a way to incentivize (bug-free) early completion of a task.


Thats a good observation.
Any ideas to incentivize early completions?

Share this post


Link to post
Share on other sites

[quote name='Tom Sloper' timestamp='1335209083' post='4934208']
You also have to play a psychological game here. If everybody knows you're adding 33% to their estimates, they might ease off on the gas pedal to fill the available time. So you might need to find a way to incentivize (bug-free) early completion of a task.


Thats a good observation.
Any ideas to incentivize early completions?
[/quote]

Simple public attaboys can go a long way. "And this week the on-time attaboy goes to Zack Zilch! Attaboy Zack!"

There can also be a toy or badge that goes to the current week's recipient, like a Flat Stanley that each recipient writes his name on as it passes through his possession before circulating to the next, or you buy a new D&D figurine each week, and see who collects the most figurines. A lot of pride can attach to very cheap little things.

Share this post


Link to post
Share on other sites
First off I want to say: Do not cut up user stories! I have seen this advice all over the place, but it is ill advised and comes from the Watterfall model. The falcy is that if you can't estimate one big task propertly then maybe you can estimate a five small tasks properly. The underlying though is that errors will even out (Law of Lage Numbers), but that is not true, small tasks have a bias towards underestimating and this results in an overall underestimation. And finally the entiere idea if a user story is that it describes one chunk of usefull functionality for the "user". If you chop them up you don't deliver that functionality until all bits are done. But now that they are choped up you stop seeing which user stories go together and you end up making the user whait longer and longer on the needed features.

Back to the topic at hand. If you are starting to catch up so much delay this early, then probably your estimates suck. You have tow options either you start to use a estimated to real time function to correct the error. This is what they do with XP, you estimate in ideal time and then convert that into real time for planing. Take your current factor and apply that to all additional estimates. A different aproach is the poject velocity, you take the number of estimated man hours you where able to do this sprint, this is the base line for the next sprint. From this you can interpolate when your expect what feature to be done. These two metrics will change over time and often improve, since you often overlook mundane tasks that need to be done.

Also if your estimates suck, you might want to look into planing poker. I think programming is the hardest to estimate task, since each problem is a new one. Although planing poker is not very acurate, but it takes into account that estimating is basically guessing and on average the result is quite solid.

Programmers are a odd bunch, I know I am one and strongly suffer from the student problem. The student problem is, no matter how much time you give him for an essay, he will use up all the time. Many programmers want to make "the right thing", which unfortunatly often leads to overengineering a problem. Ask them how they would solve the problem in half the time. I have good experiance in pushing developers to do things in shorter times and then let them refactor the bunch into a properly formed application. Just time box each step and make the programmers comit to the timebox. Honestly I found it gives better results if you give them a fixed time and variable feature set than a fixed feature set and variable time. The odd thing is they are better at maximising (more featuers) than minimaising (less time per feature).

Share this post


Link to post
Share on other sites
1. Increasing time.
2. Reducing requirement.
3. Looking for more hands.

Those are only solutions we can do.

When we say "behind schedule", it usually means there exist a due, or dead line, no matter where it comes from.

That may block the way of solution 1, or it will be the best solution, to "complete" your game. Poor game usually behave poor in market.

On other viewpoint, if your dead line comes from market, that means your product may only have chance at correct release time, choose solution 2 to match the trend of market. We still can improve(patch) bad product after right time, but we can not promote the right product at wrong time.

The 3rd solution is a myth. It only works under management with discipline. However, if you have a good management, you barely delay.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!