Jump to content

  • Log In with Google      Sign In   
  • Create Account


What to do when the project is delayed?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
13 replies to this topic

#1 BlackWind   Members   -  Reputation: 201

Like
0Likes
Like

Posted 23 April 2012 - 12:54 PM

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.

Sponsor:

#2 Nypyren   Crossbones+   -  Reputation: 4029

Like
0Likes
Like

Posted 23 April 2012 - 01:19 PM

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.

#3 SimonForsman   Crossbones+   -  Reputation: 5971

Like
0Likes
Like

Posted 23 April 2012 - 01:22 PM

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)
I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#4 Tom Sloper   Moderators   -  Reputation: 9174

Like
1Likes
Like

Posted 23 April 2012 - 01:24 PM

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.
-- Tom Sloper
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com

Please do not PM me. My email address is easy to find, but note that I do not give private advice.

#5 BlackWind   Members   -  Reputation: 201

Like
0Likes
Like

Posted 23 April 2012 - 03:24 PM

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?

#6 Nypyren   Crossbones+   -  Reputation: 4029

Like
0Likes
Like

Posted 23 April 2012 - 03:25 PM

(Sometimes) Give people Friday off if they finish early. :)

#7 Tom Sloper   Moderators   -  Reputation: 9174

Like
0Likes
Like

Posted 23 April 2012 - 04:06 PM


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?


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.
-- Tom Sloper
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com

Please do not PM me. My email address is easy to find, but note that I do not give private advice.

#8 BlackWind   Members   -  Reputation: 201

Like
0Likes
Like

Posted 26 April 2012 - 10:59 AM

Thank you.
Great ideas!

#9 rioki   Members   -  Reputation: 557

Like
1Likes
Like

Posted 27 April 2012 - 07:25 AM

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

#10 NDarkTeng   Members   -  Reputation: 122

Like
0Likes
Like

Posted 30 April 2012 - 03:25 AM

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.

#11 TMKCodes   Members   -  Reputation: 271

Like
-1Likes
Like

Posted 17 July 2012 - 08:41 AM

One thing i have realized is that we focus too much on deadlines in software development. Estimating how long it will take to code the software is hard, because software is much more complex than like building a house. Software development also usually causes unexpected problems, which might take weeks to solve if not years. The truth is that if everyone in the team actually does their job the software will be finished at some stage.

I do realize that clients want to know when they can get their software and how much cash building it takes, but I will never again work for someone who wants for example complete web CMS from scratch in two weeks, but I will take jobs with no time limit, but those will get daily reports what has been done and what problems i ran into. I will even let them watch while I code what they want.

If you do not work for clients then you really do not need deadline and you can say to your users that the software will be released when it is ready, like Arenanet is currently doing with Guild Wars 2.

Then again you will need to supervise that everyone will work instead of seeing if they complete their deadline.

If you have limited budget and you run out of cash, then you have a problem which is hard to solve and deadlines kinda try to solve this by forcing the software to be developed before cash runs out, which leads to firing developers who actually are good but are not willing to work extra hours to meet the deadline. So if budget runs out before the software is finished you either have big problem and will have to stop development of the software or halt it until more cash is found. Though if you are working for a client do not charge for completing the project, but for developing the project, because clients of course expect to get finished product with the cash the budget they have.

Of course you can still try to estimate if the budget runs out before starting to write code, but do not try to make miracle happen, because you most likely will be late anyway. Trying to think how to make the miracle happen is just waste of time and makes you even more late. Just apologize to the client and kindly ask if they can but more cash in to the budget or start dropping features to make the work load smaller.

Software development deadlines can just fuck off. It is not like god had 6 day deadline, he is god and finished it in 6 days instead of 6 years.

#12 Tom Sloper   Moderators   -  Reputation: 9174

Like
0Likes
Like

Posted 17 July 2012 - 09:11 AM

TMK,
The OP was asking from the point of view of a project manager, and he got answers almost 3 months ago.
Your reply does not address the question that was asked.
-- Tom Sloper
Sloperama Productions
Making games fun and getting them done.
www.sloperama.com

Please do not PM me. My email address is easy to find, but note that I do not give private advice.

#13 TMKCodes   Members   -  Reputation: 271

Like
0Likes
Like

Posted 17 July 2012 - 09:39 AM

Tom i am sorry that i did not notice that this is 3months old. I gave my opinion with the perspective of project manager, but kinda as the software developer too. I have managed open source game project of about 20 people and i did not enforce deadlines, because i feel that they should not exist not because they were working for free. Though as they were working for free it was kinda hard to get them do stuff every day.

I did answer his questions, but i kinda told him to forget about stuff like delays, because without a deadline you can not delay.

#14 Orymus3   Crossbones+   -  Reputation: 7071

Like
0Likes
Like

Posted 17 July 2012 - 07:56 PM

Since this was reopened...

We have only been 6 weeks in production and the project has already "2 weeks late"

I find it peculiar that the project is '2 weeks late' while its actually handled as an agile/scrum project.
As Ken Schwaber would put it, its done when its done. Am I to assume this was a measure of how many failed sprints occured? If so, what was the iteration length?
The issue might be at the iteration level, and not necessarily within the technical evaluations (task allocation for the sprint in regards to other tasks).

From the perspective of a PM, I tend to allocate static % to specific tasks.
For example, I account for the fact that resources only actually work about 80-90% of the time they 'work' (there are meetings, chat, in-between task setups, etc).
In general, I buff my tasks by 41% and, given I do my job right, that's generally the time it really takes. This number is generally increased as the hierarchy of the project increases (that is, when people are expected to interact with more people). I also tend to evaluate the efficiency of leads based on how many people they have to coach. After 4-5 people, they pretty much lead fulltime and don't produce any actual work (this is something a lot of PM that I've seen overlook when tasks are allocated).

It is true that other people on the team focus only on the task itself and may not see the whole, but its not the only answer.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS