 |
||
  |
||
| Pain
Is Good (Just Not My Pain!) |
||
| Customers
cringe when I say this, but I keep pointing out that Phase I of any LIMS
project is “The Phase of Pain.” It would not be honest if I tried to pretend this is not the case. In any project, not just a LIMS project, the goal is to implement a system that performs as required, comes in within budget, and ends on time. Projects that meet these criteria rarely contain all the desired functionality in the first phase. Nor should they, in most cases. If you were to take a critical look at every item that is requested on a project, and if you were able to determine a likely length of time needed to accomplish each one, you would usually find that you cannot do all of them and come close to an ending date that sounds reasonable for the initial project roll-out. The act of breaking the project into phases also makes it more manageable. Smaller chunks are easier to manage than larger ones, partly because they are easier to keep on-track and easier to save if they go off-track. One way to break a project into phases is to install a “base” system, first (i.e., one that does the basics of logging samples, and the like, but little more), and adding big pieces in each subsequent phase (e.g., adding a stability management piece might be a single phase). One of the most popular methods used to break the project into phases is to rate items by their relative importance. This exercise not only allows work to be prioritized into manageable phases, it also forces those involved with the ranking to rethink which items are their “mission-critical” pieces of functionality. Some of you are about to say the following: “What if my users won’t rate the items? They say all are equally important. They say that if they rate them, then the items getting a lower rating won’t get done.” First of all, it is not possible that every item in the system is of equal importance. If a user gives me a stack of tasks and does not rank them, how will I know which to do first? This is what it means: If a user does not rank the work, the person who does the work will rank it, but their ranking will not be based on the same criteria as what the user might have decided on. For example, all tasks being equally-ranked might mean that I would take the first one I see, or the one that most interests me. On the other hand, there might be one in the stack that the user is waiting for and would like to see before some of the others. If I am assigned more tasks than I am given time to do them in, the item that the user might want the most might be the one that I do not even get to. Then, you might consider pointing out to your users that if they do not rank their requests, the person doing the work would have to. You might also mention that that ranking probably will not be one that they would approve of. When put to them in this manner, most people realize that they do not want someone else ranking the tasks for them. If your users still will not rank their items, consider the idea that they are honestly afraid that once they do the ranking that they will not get low-ranking items finished in future phases. This might be valid, depending on their experience with other projects. If your company has a habit of partly-finishing projects by installing in one phase and doing only the top-priority items, and your users have seen this happen on a regular basis, I do not blame them for refusing to participate. Still, to finish the project on-time, someone might just decide to “help” them choose by choosing for them, and that would not benefit them, either. It is also a fact that a successful and highly-usable system does not usually end up with every requested item being included in the project. Some of the nice-to-haves end up being too complex to include. In the end, breaking up a project into phases requires some extra coordination, and a lot of trust between all that are involved in the planning. As I said earlier, Phase I is “The Phase of Pain” but don’t get upset with me for pointing that out. After all, I’m just the messenger. |
||
| © GeoMetrick Enterprises 2001 - 2006 |
|
|