A recent court case in Europe has highlighted a right that many would not immediately list in the top rights most important to them - the right to be forgotten. Privacy expectations in Europe are different from the United States, as Google found out as it took pictures all over Germany for its popular Street View service. But what about the right to have links removed which refer to old newspaper articles about something that happened a decade or two ago? It happened. There was a newspaper article about it. It's public information. Things change over time, and it's old news, but should the original articles still be searchable? Technology is an enabler. It helps you do what you want bigger and faster than you could without it. But that doesn't mean you can always control it. The man suing for removal of a past legal issue now shows up in more search results than he did before, magnifying the discussion around him. So how do you effectively leverage technology to magnify the positive and manage the negative without it getting out of control on you? That's the tough question to ask in your organization.
More on the Right to be Forgotten:
http://www.legalweek.com/legal-week/blog-post/2346341/the-right-to-be-forgotten-case-google-right-this-time-ecj-hopelessly-wrong
http://www.computerworld.com/s/article/9249793/Microsoft_offers_European_Bing_users_the_right_to_be_forgotten_
Thursday, July 17, 2014
Tuesday, July 8, 2014
Managing the Critical Path
When planning a project, the temptation is always there to build in extra time everywhere so that your schedule never slips. Just like if you're putting in tile or carpet, you order 10% more than what you measure that you need in case something gets damaged or if you mis-measured. Time is the biggest resource you have on a project, and the most visible "failure" you can have is missing your launch date. So it makes sense that you would add 10% or some other fudge factor to all your estimates, right? Not so fast. If you have a time-sensitive launch, set the completion date well enough before you really need it, but don't just give everyone extra time to get everything done.
The critical path is the sequence of tasks that need to be completed on time for the project to complete on time. If you have slack built in between tasks early on in your project, then what you've done is made it so those tasks can be delayed without changing the completion date. By definition, if tasks can be delayed and not affect the project completion date, they are not critical. If you do something like this, you'll end up with a very short critical path, with just the last task or two showing in red, meaning the last couple have to be completed on time. That makes sense if you look at it logically. It may be logical and possible, but is it allowed? I'm not sure I can answer that question or even if I can that I want to. The better question than whether it's allowed is whether it's a good idea. And that, I can say emphatically, is not a good idea.
Anyone looking at your Gantt chart or network diagram will expect a critical path. There are many ways you can show that, and there are many possible ways to put together a project. You can have a completely sequential project, in which case only one task is being worked on at a time and everything is on the critical path. It's neither logical nor desired, except in the rarest of circumstances, to have every task be on the critical path. On the opposite side of the pendulum, it is neither logical nor desired to have only a couple tasks or even no tasks on the critical path. At its most basic level, the critical path is really just a calculation. It is what it is. You simply measure the lengths of the various paths and the longest one is critical. At a more strategic level, the critical path is key to your management of the project, as it is the series of tasks that you will be watching most closely for scheduling issues. If everything is critical, or if nothing is, then you have nowhere to focus your attention, and the project just kind of does whatever it wants. You can probably see how that might be a bad thing.
Building in slack between tasks, aka giving people extra time to finish their tasks, is not meaningful or helpful and if anything is damaging, because if you give them extra time, they will take it. If you give someone a 1 week task but give them 2 weeks to do it in, they will wait until the second week to start. The idea is probably so if they end up taking 6 days instead of 5, the schedule doesn't change. That's good in theory, but if they have a 1 week period to do their work and start week 1 and go one day over, they are just one day late. If they have two weeks and start week 2 and go one day over, they are now 6 days late. Even if they have 2 weeks and start at the beginning and finish in 5 days, there is a phantom 5 days that everyone else is going to be sitting around waiting. Why tell the next team they can't start work for 5 days when the previous work is done, just to maintain the schedule? If there are things that have to happen on a certain date, well you hard code those and work around it. But those are pretty rare. If you want to build in some slack, put that at the end. If management wants things done by the end of the year, you plan the project to complete, say, October 31. But the project due date is published as October 31. You don't tell everyone that the goal is Halloween but you don't care if it's not done until Christmas. Stick to Halloween. If it does go over by a week, we'll all survive. But the second you start telling people your "real" go-live date, that's the date everyone will be aiming for and before you know it, New Years' comes and goes and everyone is still trying to wrap up loose ends that should have been done 2 months prior.
The critical path is the sequence of tasks that need to be completed on time for the project to complete on time. If you have slack built in between tasks early on in your project, then what you've done is made it so those tasks can be delayed without changing the completion date. By definition, if tasks can be delayed and not affect the project completion date, they are not critical. If you do something like this, you'll end up with a very short critical path, with just the last task or two showing in red, meaning the last couple have to be completed on time. That makes sense if you look at it logically. It may be logical and possible, but is it allowed? I'm not sure I can answer that question or even if I can that I want to. The better question than whether it's allowed is whether it's a good idea. And that, I can say emphatically, is not a good idea.
Anyone looking at your Gantt chart or network diagram will expect a critical path. There are many ways you can show that, and there are many possible ways to put together a project. You can have a completely sequential project, in which case only one task is being worked on at a time and everything is on the critical path. It's neither logical nor desired, except in the rarest of circumstances, to have every task be on the critical path. On the opposite side of the pendulum, it is neither logical nor desired to have only a couple tasks or even no tasks on the critical path. At its most basic level, the critical path is really just a calculation. It is what it is. You simply measure the lengths of the various paths and the longest one is critical. At a more strategic level, the critical path is key to your management of the project, as it is the series of tasks that you will be watching most closely for scheduling issues. If everything is critical, or if nothing is, then you have nowhere to focus your attention, and the project just kind of does whatever it wants. You can probably see how that might be a bad thing.
Building in slack between tasks, aka giving people extra time to finish their tasks, is not meaningful or helpful and if anything is damaging, because if you give them extra time, they will take it. If you give someone a 1 week task but give them 2 weeks to do it in, they will wait until the second week to start. The idea is probably so if they end up taking 6 days instead of 5, the schedule doesn't change. That's good in theory, but if they have a 1 week period to do their work and start week 1 and go one day over, they are just one day late. If they have two weeks and start week 2 and go one day over, they are now 6 days late. Even if they have 2 weeks and start at the beginning and finish in 5 days, there is a phantom 5 days that everyone else is going to be sitting around waiting. Why tell the next team they can't start work for 5 days when the previous work is done, just to maintain the schedule? If there are things that have to happen on a certain date, well you hard code those and work around it. But those are pretty rare. If you want to build in some slack, put that at the end. If management wants things done by the end of the year, you plan the project to complete, say, October 31. But the project due date is published as October 31. You don't tell everyone that the goal is Halloween but you don't care if it's not done until Christmas. Stick to Halloween. If it does go over by a week, we'll all survive. But the second you start telling people your "real" go-live date, that's the date everyone will be aiming for and before you know it, New Years' comes and goes and everyone is still trying to wrap up loose ends that should have been done 2 months prior.
Subscribe to:
Posts (Atom)