AceProject Logo
AceProject Community
The official AceProject user community.
Go Ahead, Manage » All Tags » time management (RSS)

Browse by Tags

  • Dates, Dates, Dates

    Spore is the computer gaming world's most anticipated release. Well, it was in 2005, and in 2006, and 2007. It should be released this month. Wired has a nice recap of the release dates' evolution. Two whole years late. Spore has been set to release "in a few months" for the last two years. How does that happen? While it's perfectly understandable to have problems and delays in the development of such a groundbreaking game, I am curious to know what made the game so late. When the creators demoed the game at the E3 conference in late 2005, they expected the game to be finished and ready to ship. And yet, we are almost 3 years later and it has not been released. Is this a good example of bad project management, or a yet better example that, no matter how well the project is managed, sometimes Murphy weighs heavily in the balance?
    Filed under:

  • Can time be managed?

    I am presently working on a glossary of terms related to project management. As I was looking for definitions of time management, I found this interesting comment on Wikipedia : "In a 2001 interview [2] , David Allen observed: You can't manage time, it just is. So "time management" is a mislabeled problem, which has little chance of being an effective approach. What you really manage is your activity during time, and defining outcomes and physical actions required is the core process required to manage what you do." Yet another thing to ponder. Time goes by at a constant speed, regardless of how we feel about or what we are doing. But what can we do? Everyone can make the best of their time. In a project, it's important to wonder if those 4-hour meetings are really an efficient use of the team's time (they're not). We shouldn't think about managing our time, but about using our time efficiently. Is it more efficient to research a problem for several hours on Google or to ask your colleagues about the solution? Is it more efficient to update your AceProject tasks with the latest info, or to tell each person individually about it? Is it more efficient to email everyone a document and manage comments in the email replies, or to send them the link to the document, and have them type their comments directly in the project management system? Old habits are hard to break, but they're often worth the effort and will free up some time in your busy schedule.
    Filed under:

  • Task dependencies

    Most projects require that some tasks are accomplished in a specific order. For example, in a publicity project, the marcomm firm will want the client to approve the design before it goes to press. When the client, the representative and the printer are not in the same city, the risk of the file going to print too early can get pretty high. Ask any printing company how pleasant that is. If you want to make sure that your client approves the design before it is sent to print, set up your client project in AceProject, and link the client approval task to the printing task with a dependency: Once there is a dependency, you won't be able to open a task, unless the previous task is completed: And in the Gantt chart, it's easy to see how the tasks are linked: However, what I like most about task dependencies is how task dates are dynamically linked. For example, let's say your client is gone on vacation for two weeks and won't be able to approve the brochure. All you need to do is change the due date for the approval task and all its subsequent tasks will be moved on the schedule too. Even nicer: everyone assigned to the subsequent tasks will receive an email about the date change. Talk about efficient!

  • Fake emergencies ruin it for the rest of us

    It's part of my job at Websystems to reply to email enquiries about AceProject. I get asked all sorts of questions, from pricing to features to integration with external systems (via CSV files). I enjoy replying to these emails because they give me a good idea of what our clients are looking for in a project management system. I try to reply to all email within one business day, usually faster. Every once in a while, I'll receive an email with the red question mark ( ! ), or URGENT in the subject line. Obviously, I'll look at those emails first, in case there is an actual emergency with this client. Most of the time, there isn't. The sender simply thought she would get a faster response by labeling her message as urgent. She did succeed in grabbing my attention. However, a request for our pricing hardly qualifies as urgent, especially considering that the information is actually available on our web site. Often, once I've replied to those "urgent" emails, I won't get a response from this person for a few days, further proof that the emergency was not real. I've also encountered these fake emergencies in person. I had a colleague who would mask her poor time-management skills with emergencies. A rerquest for pricing (RFP) would sit on her desk for a week of more, and she would bring it to my attention only when the deadline was just a few hours away. She lived in a constant state of emergency. The problem was, when she actually had an urgent request, no one would believe her. This ruins it for the real emergencies How can I trust that messages marked URGENT are actually emergencies, when 90% of the messages labeled URGENT really aren't? How can I trust someone telling me something is urgent, when ALL they ever deal with is urgent? It's the business world version of crying wolf.
    Filed under:

  • Do you account for summer vacations?

    Here at Websystems, we are starting to feel the summer groove coming on: we are seeing more and more vacation automated replies to emails. More than that, it seems the summer season puts people in a different mood: happier and mellower. It makes our jobs that much nicer, which is always appreciated :-) This reminded me of scheduling and summer vacations. In North America and Europe, most of us will take a few weeks of vacation time in the summer. From a project scheduling perspective, this can have heavy consequences on delivery times. With most of the team off work, things will not get done as quickly as they would in the summer. When assigning tasks to your team, it should be taken into account, especially with time-sensitive tasks. One way to keep track of everyone's vacation would be to create a project called "Vacation Dates" and let everyone create a task for their vacations, with 8 hours of estimated time per day of vacation. This way, the person would show up at completely booked on the workload report. You could also print a Gantt chart of your team's vacation schedule, as a reminder. What's your technique? How do you keep track of vacation schedules and meake sure someone doesn't get scheduled to work during their vacation?

  • Now that you're late, how do you deal with it?

    Being late happens, even to the best projects. And when it happens, you need to deal with it. The longer you ignore a delay, the higher the chances of the delay growing longer. So how do you deal with a task being late in your project? Or the project itself being late? Oh my god Oh my god Oh my god Oh my god Oh my god Oh my god Panic. Run around in circles. Feel really bad about it. Does it make the delay better? It at all, it makes things worse. There is nothing to gain from panicking about a delay. It's not my fault Trying to avoid the blame maybe understandable, I fail to see how it gets you on the track to being on time. Would it be worse if it was your fault? At least you could do something about it! It's [insert name]'s fault While the blame game is an all-time favorite, here again I fail to see how that helps the project. Pointing fingers takes time and if you're late, you can't afford to waste time focusing on who messed up. Why it's late When we start trying to understand the delay, something can be done about it. However, understanding the why of something is only the first step in fixing the problem. And that's what we want to do: find a way to reduce or eliminate delay. What are the consequences? Is your project linked to a contract that includes penalties if you're late? Are you working on the President's pet project? Has your organization committed publicly to a date? It's important to know the implications of the delay, since they will affect how much effort is required to correct the situation. It's also important to find out is the project team knew about those consequences beforehand. Even though it's always important to be on time, knowing there's a 10% penalty for delivering a product late can help your team take measures to prevent delays, or plan countermeasures to correct a delay. Get over it Time only goes forward. The project is late, and there is nothing that can be changed about that, unless you have a time machine. No good will come out of commiserating about the delay. How are you going to fix this? This is the tough question. How can you fix what made the project late in the first place? How can you gain time to recover from the delay by the end of the project? How can you prevent this type of delay from happening again? Think of the future If you treat each challenge as an opportunity to improve your project management skills, then no delay or failure is entirely negative.

  • Get your fudge ratio

    Not, it's not how much fudge you can cram in yourself before you start feeling icky (although I wish!). The fudge ratio, as explained in this post from LifeHacker, reflects how good you are as estimating the time required to accomplish something. To get your fudge ratio, you must compare your time estimates with your actual times. Here's an example: You estimate it will take 1 hour to implement changes to the company's website. It turns out Murphy had his way and it took you 2 hours to implement the changes, meaning 200% of the estimated time. You estimate it will take 2 hours to correct a database query, but you found the error faster than you though you would and it only took 30 minutes to fix it. In this case, your actual time is 25% of the estimated time. You estimate it will take 5 hours to design a new application logo, but you forgot about the approval process and it ended up taking 8 hours, 160% of the estimated time. If you keep tracking estimate VS actual time, you will be able to get an average fudge ratio. In the example above, if we make an average of the individual fudge percentages (200, 25, 160), we end up with the fudge ratio of 128%, or 1.28. When you know your fudge ratio, as the LifeHacker post explains, you can pad your estimates accordingly. This will help you give more accurate estimates. The problem: most of us aren't very good at taking notes Let's face it: most of us will start with good intentions of keeping a spreadsheet somewhere with the estimated numbers and the actual numbers. Unfortunately, as deadlines get closer and the task pile keeps getting higher, we'll forget to keep the spreadsheet up to date and we will never be able to accumulate enough data to get a good fudge ratio. Most of us, however, use a project management system. Most project management systems already include estimated times for tasks. As you work on your task in AceProject, you can log your time for that task very easily: Fill out a time sheet at the end of the week Add to your time sheet directly from the task Just start a timer. To get your fudge ratio, all you have to do is go in My Office and customize your task list with the Actual % Done field included: With a task list like this, you can automatically see whether you tend to be optimistic with your estimates. Export your list to Excel, get an average from the Actual % Done and there you are. You have your fudge ratio. Now that you have it, don't be afraid fudge things up Now that you've got your fudge ratio, use it. When you're making estimates, remember your fudge ratio and apply it. If we use our example's fudge ratio (1.28), when estimating a task to take 10 hours, you should put in 13 hours (10 multiplied by the fudge ratio of 1.28). This allows breathing space for Murphy's Law to affect your project.

  • Project management and time management

    It seems to me that, while one can manage his/her time outside of a project, it would be difficult to manage a project without managing time. I could not imagine a project with a set of tasks, and no dates. How can one plan without time references? On the other end of that spectrum, if a project is late, can it still be considered successful? In some industries, being late is part of the deal, it's normal and expected. However, in other businesses, being late mean penalties and a tarnished reputation. So, what is the most important: doing it right, or doing it on time? My position here would be both. It's no use delivering something on time, if it's not fully completed and functionnal. There is nothing worse for a comapny's reputation than a beta-level product released. Clients will forgive lateness to a certain extent, but they will not forgive and product that doesn't work. However, there is a limit to a client's patience. Sometimes, when trying no to make it right, but to make it perfect , we miss the window of opportunity for the product. Either another company beats you to market, or the need for the product has disappeared. Just think of the company trying to develop the perfect BETA tape... We have to do it right, and not too late.
Copyright © 2001-2010 Websystems Inc, owner of AceProject