• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
BlackWind

What to do when the project is delayed?

13 posts in this topic

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

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote name='BlackWind' timestamp='1335207267' post='4934200']
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.
[/quote]

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 [b]should[/b] 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)
0

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

Share this post


Link to post
Share on other sites
Thank you guys.


[quote name='SimonForsman' timestamp='1335208969' post='4934207']
Don't allocate time on a programming task based on how long it [b]should[/b] take
[/quote]

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 ?



[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.
[/quote]

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

Share this post


Link to post
Share on other sites
[quote name='BlackWind' timestamp='1335216241' post='4934239']
[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.
[/quote]

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

Share this post


Link to post
Share on other sites
First off I want to say: [b]Do not cut up user stories! [/b]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).
1

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

Share this post


Link to post
Share on other sites
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.
-1

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
Since this was reopened...

[quote name='BlackWind' timestamp='1335207267' post='4934200']
We have only been 6 weeks in production and the project has already "2 weeks late"
[/quote]
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.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0