Define Success

While working with a customers project manager, preparing to create the plan for their upcoming LIMS project, I was asked how we know how much to put into the first phase so we could meet the project deadline. My answer was that we could put as littl

Written byGloria Metrick

| 2 min read

Listen with Speechify

0:00

2:00

While working with a customer’s project manager, preparing to create the project plan for their upcoming LIMS project, I was asked how we know how much to put into the first phase so we could meet the project deadline. My answer was that we could put as little as we wanted into Phase I in order to make it meet its calendar deadline, but that it’s ridiculous, at a certain point.

Too Small

For example, I pointed out that Phase I could merely be the implementation of User IDs, allowing everyone to login. Thus, we could easily make the deadline and easily declare Phase I a success. However, no one would bother using the LIMS merely to login. Our success based on meeting the calendar deadline would not really be a success at all, if you based it on providing users with something that added value to their process.

If this example seems ridiculous, I’ll point out that I do run into projects where the first phase provides a ridiculously low amount of value just so the project team can guarantee that they can declare it a success and maintain a straight face while doing so.

Too Large

The other extreme, where you ignore the calendar deadline and put everything you can into the system to provide every possible bit of value to the user, isn’t necessarily any better. This is known to many as the “Big Bang” approach. It’s likely to blow up not just your project schedule, but budget, as well. This approach is destined for failure and seldom leads to the “go live” situation. If these projects do “go live,” it’s because they were scaled back enormously. Ironically, they often end up so scaled back that they also end up providing very little in the final installation. That is to say that they often end up in the “too small” category.

Just Right

For a reasonable Phase I, pick carefully among (notice that I didn’t say “pick ALL of these” but rather, “pick from among these”):

Items used the most. For example, sample types used only once a year shouldn’t be selected over those used every day for Phase I implementation.
The highest throughput items. In most laboratories, data entry and review is done quite a lot. Providing users with the ability to do this well is more important than providing a means of handling occasional exceptions.
Those options that save the most time and effort for the users.
Choices that provide system integrity.
Items that would be extremely difficult to retrofit into the system at a later time.

In Closing

There’s no guarantee that you’ll select exactly the right items that will both make your first project phase short as well as give users a maximum of functionality for the time spent. However, the goal is to get as close as possible by selecting wisely. That’s the way to define success.

Too Small