Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Businesses Programming IT Technology

Tracking Dynamic Completion Dates in Development? 39

cronostitan asks: "We are a small software development department inside a big print media corporation. As in most departments nowadays, we have very few people but a high workload. We are currently working on a code rewrite of an in-house CRM application. Beside this big project, there are always a number of urgent, smaller projects coming in with a timeframe of 1-3 days that we do 'in between.' There is no way to delay these small things, as these are always of the highest priority." What's needed here is a time tracking system that automatically adjusts completion dates based on the current workload. Read on for more details of cronostitan's situation.
"The problem is that if we set a completion date for the CRM project it is always delayed by these smaller projects. Since I am doing the project management, I am a little desperate, since I can never tell my superiors WHEN the real completion date will be. My idea was to find software where you have your usual project management function (with GANTT charts, etc.) to preview the managed project(s), but also have some type of individual time-tracking for 'in between' projects and daily works. Whenever time is spent on any of these urgent projects, the completion date of the CRM project should be shifted dynamically into the future. This would require a login into this imaginary tool so that developers can track what amount of time is spent on specific projects, so that an accurate timeline can be kept. Does something like this exist, preferably as OSS? Do we have to invent the wheel again, or are we going down the wrong path?"
This discussion has been archived. No new comments can be posted.

Tracking Dynamic Completion Dates in Development?

Comments Filter:
  • by Neil Blender ( 555885 ) <neilblender@gmail.com> on Wednesday June 08, 2005 @07:30PM (#12763384)
    Each day you spend working on something else, move your 'Project Completion Date' magnet one day forward. Be careful though - if you do something else on Friday, be sure to move the magnet to Monday, not Saturday.
  • Recommended Reading (Score:3, Informative)

    by Vaevictis666 ( 680137 ) on Wednesday June 08, 2005 @07:36PM (#12763444)
    Some recommended reading on the topic of scheduling: Painless Software Schedules [joelonsoftware.com]
  • by Anonymous Coward
    Call Center, Bug Tracking and Project Management Tools for Linux

    http://linas.org/linux/pm.html [linas.org]
  • by biglig2 ( 89374 ) on Wednesday June 08, 2005 @08:42PM (#12763980) Homepage Journal
    Well, actually a subtle blend of old favorites. Let me consult my reference document on "the 25 reasons projects fail".

    Well, this is mostly #11, "plan over-estimates resource" and #14 "responsibilities unclear". Your actual question, of course, reveals that you are also suffering from #7, "Planning tools are unwieldy" since you are asking for a tool to fix your problem for you, instead of fixing it. Project managers always over-rely on their tools.

    What you need to do is to have proper negotiations between the two critical players, the Project Manager and the Line Manager. This should be both easy and hard, since it sounds like you are both of these people.

    Definition: Project Manager is in charge of the project, and the Line Manager "owns" the resources the PM needs to do the project. What must happen is a negotiationbetween PM and LM where LM agrees to give a certain ammount of the resource to the PM. This has to be stuck to - although it can be hard.

    So, you as LM have to say to you as PM, "I can give you three days a week of my boys. I can't giv e you 5 days, sorry, because all these small urgent projects pop up all the time." As LM, you have worked out how much time on average you need your boys for the firefighting.

    Then, you as PM, can use you planning tools and work out how long it is going to take, given that you have only 3 days resource a week.

    • <aol lamer>ME TOO!</aol lamer>

      Seriously, I'm in the same situation as the op. When asked for a deadline, we always assume we have 3 days to work on the project. It has proved to be pretty accurate, removing the need for a crunch week.

      Trevor
      • A better technique is to break down your development planning into stages, then give approximate "uninterrupted time" estimates for each stage, and an approximate completion date for the current stage.

        Each time one of these "hi priority" tasks comes down the pipe, double your estimate on how long they will take, push your completion date for the current stage forward that much and notify everyone important of the fact when you take on the job, then use any extra time you bought to get ahead of the game on
        • This is part of my idea too, at times there is a need for PM and LM to re-negotiate, with the corresponding hit on the project plan.

          BTW, watch out here too for #8, "Obsession with Due Date". Due dates are not always as important for a project as people think. People like hanging a date on things and then measuring the project by how far away that date is, but in real life projects are often not vitally time-bound.
  • by fred fleenblat ( 463628 ) on Wednesday June 08, 2005 @08:51PM (#12764035) Homepage
    It sounds like you are not so much interested in the effect on the schedule, but in finding a way to prove something to your superiors.

    If they are like other managers, the reality of the situation is irrelevant. They will make unreasonable demands and you will be held responsible when the demands are not met. To them, all the graphs, charts, timelines and other stuff is just part of your whining.

    In fact, it is in their interest to make you fail so that they look good in comparison and then they are more likely to get a raise/promotion/whatever.
    • Not always true.
      In my company (when I say "my company" i mean my employer), We have begun using MS Project to plan our future. We also add all of our scope creep and distractions to it during our Mon., Wed. and Fri. meetings.

      We do it for many reasons:

      To document the cruft that builds.

      To manually move the finish dates as needed
      (Unfortunatly, MS project does not selectively level a project.) Some line items become hot, others get pushed back. Resources are averaging 300% per head.

      Keep the PM i
    • If they are like other managers, the reality of the situation is irrelevant. They will make unreasonable demands and you will be held responsible when the demands are not met. To them, all the graphs, charts, timelines and other stuff is just part of your whining.

      I get the impression that you and I are both in the same situation: We've been there before and have grown bitter at our own inability to change the situation (and management's refusal to change their own behavior). It's unfortunate that this i


  • I'm in the same boat and I know you just can't predict the future in this scenario but...

    If your people are keeping track of their time spent accurately and you know their skills well enough: Do your project planning strictly in hours required and set clear milestones. Then try to establish an average of daily/weekly time spent on the rolling project and adjust your completion date accordingly - with a little padding for coffee breaks.
    • You should be alittle honest.

      1. - If your CEO has a strong marketing background, your release date is whenever the customer said so.

      2. - If your CEO has a strong financial background, your release date is whenever the customer shows money.

      3. - If your CEO has a strong sales background, it's ready before the first line of code is written.

      4. - If your CEO has a strong technical background and not in the development trenches with you. See Number 1.


      • 5. - If your CEO is like mine, the completion date is when you tell him it is - rolling or otherwise.

        6. - If your CEO is like yours, you're probably too miserable to give a shit.

        7. - If your too miserable to give a shit, your probably right where you belong - nestled in the bosom of Corporate Pulp Culture.
  • Figure how many requests have come in, or what time. Assume that this trend will continue. Assume that your team will continue to spend x% of their time on the project.

    Do make sure you account for time getting back into the code after the urgent project though.

    • Back when I was scheduling projects we used a loading factor for our estimates. Say after estimates we figured the next release would take 20 days to finish. If our loading factor was 50% (meaning we could only devote 50% of our time to the project due to various emergencies, "things" that pop up, etc.), then the project would be scheduled as taking 40 days to finish. Worked like a charm.

      If you know that your team can't devote 100% of their time to the project, don't schedule it as if they can.

  • by Anonymous Coward on Wednesday June 08, 2005 @11:01PM (#12764881)
    These gantt charts and complex packages never work. They just give you the illusion of control! They make you think that if you stuff all your data into the computer, somehow your project will guide itself.

    That just ain't how it works.

    I could give you a big lecture here, but here's all you need to know as a project manager: how to say "NO".

    Once you master that, projects suddenly start meeting deadlines.

    Personally the most complicated software package I use is basecamp [basecamphq.com], which is basically a bulletin board with milestones.
    • ...here's all you need to know as a project manager: how to say "NO".
      Yep, that's pretty much it. Consult with your users and management re what the priorities are, commit to them, re-evaluate them when necessary. The nice thing about it is that conflicting priorities are brought to light quickly, evaluated, and acted upon (either by saying "no", or by bringing more resources to bear).
  • ... any of the Agile project management methods? I am using Scrum [controlchaos.com] and it works perfectly for this kind of situations.
  • Right Media started using Version One a while back: http://www.versionone.com/ [versionone.com] - it's very powerful, and definitely built around the mindset of an dynamic environment.

    I wish it could do a better job of managing bugs as well as features/releases/products, and the UI isn't quite there, but all-in-all it's a solid product.

  • This isn't hard. You don't need a complicated tool. In fact, all you need is a bag of Gummy Bears [wikipedia.org]. Take the features you have left to do, and divide them up into small tasks -- 3 days each, say, of uninterrupted time. Make each task equal to 1 gummy bear. Count out gummy bears totalling the number of tasks left to do. Put them all in a bowl. When a developer finishes a task, remove a gummy bear. Enjoy. Any time you want to know how much time is left, count out the remaining gummy bears and multiply by 3,
    • This doesn't account for a developer with a sweet tooth, or when several of the gummy bears get stuck together.
  • My company uses Tenrox (a timesheet system) and MS Project Enterprise to track projects.

    Apparently (IANAPM) line items show up in the timesheets, people update the timesheets with estimated time-to-completion and hours worked, and the schedule automatically adjusts in Project.

    It's probably only good if you're a Windows shop, though. The Tenrox system has the worst of both worlds, web-based, but uses ActiveX controls, so you need IE [sigh]. I also don't know how well it works.

  • Agile? (Score:3, Informative)

    by Ramses0 ( 63476 ) on Thursday June 09, 2005 @09:58AM (#12768262)
    Do some reading on Ward's Wiki:

    http://www.c2.com/cgi/wiki?WelcomeVisitors [c2.com] ...specifically "Velocity":

    http://www.c2.com/cgi/wiki?MeasuringProjectVelocit y [c2.com] ...and maybe take a look at X-Planner type software.

    http://www.xplanner.org/screenshots.html [xplanner.org]

    I'm also a fan of the gummy-bear model, and regular, working customer demonstrations. Provide value as early in the process as possible, not as late as possible. If you don't have your deliverables specified, you'll never know when you're done. Thus, Nail down your deliverables, break them into equal sized chunks, complete them and demo them to your customer, and determine your project's velocity after 2-3 iterations of doing the above.

    --Robert
  • by Anonymous Coward
    http://www.dovico.com/ [dovico.com]

    You won't find anything better for reporting on projects, ETCs, and Actual vs Estimate times.
  • I lead a team that has development and maintenance responsiblities. For scheduling new tasks, I use each team member's average non-maintenance time. If someone usually spends half their time handling emergencies, then they count as 1/2 a person. Then I usually add 50% to the total time because things always go worse than I think they will. <g>
  • Seriously a customer(user) is given your deadline, then you constantly move it back to adjust for other work. That is what gives IT a bad reputation.
  • What you are talking about is a task perfectly suited for Microsoft Project. Easy to set up, easy to maintain. Runs under WINE if you don't have a Win box available.

The solution of this problem is trivial and is left as an exercise for the reader.

Working...