What are we really trying to accomplish?

As a certified Project Management Professional (PMP) and a Ph.D. in Computer Science, I realize the importance of clearly stating the purpose of a project or an application.

For many, it is difficult to take the time to work through the process of defining what is really needed.

While there are tools such as rapid prototyping and Rapid Application Development (RAD) available (see http://en.wikipedia.org/wiki/Rapid_application_development for more info), they do not remove the need for the eventual end users or the sponsor of the project to articulate in his or her mind what is really wanted.

To a large extent, my experience has shown that the more specific and constrained the requirements, the greater likelihood the project or application will succeed. The real world, however, does not always allow us to keep things as straightforward as we would like them to be.

So how do projects and applications get started? Someone identifies a need. Perhaps it is a need to do automate a repetitive function so that it can save the company money. Perhaps it is collecting information in a clinical trial for making a submission to the FDA. Needs can be small, and they can be very large.

Once the need is identified, the questions begin. I like to think of the 5 Ws and 1 H (see http://en.wikipedia.org/wiki/5_Ws). This is the hard (some may say annoying) part of starting a project. All the questions need to be asked, and some many times over until as many "clearly stated" answers as possible are obtained. The biggest question, and the one in my experience that leads to all the others, is why? Why are we trying to do this? This question is then followed by, "What are we really trying to accomplish?"

The "why" should be asked repeatedly to ferret out as many reasons as possible. Some of the first reasons we come up with might not be the most important. Some of the non-obvious reason(s) why might cause user acceptance problems if they involve issues with human performance or personal productivity. Knowing these reasons in advance will help a project or application be successful.

Once we know why we think we need to do something, we then need to define what we intend to do. To some extent, this is a question of scope in that it might involve how much of the problem we will attempt to bite off. Again, the question of what we intend to do should be asked repeatedly so that we can compare options and decide if we are addressing the most important parts first.

If we do the "why" and "what exactly" well, the rest will follow in a much easier fashion.

So, why did I write this???? :-) Certainly I did it to share my experience, but I also did it in hopes that I can help you answer these questions in your next project.

Planning Ahead

Preparing to attempt to avoid "emergencies."

One of the discussions I have been having with one of my clients is that we cannot always justify taking as much time to do something as we want. One just needs to think about an ambulance on their way to an auto accident. Time is of essence, it is life or death in some cases.

The key is that the ambulance is ready before hand. The ambulance is stocked with supplies. The ambulance personnel are trained and ready to go. They minimize what might go wrong while they are not in an emergency.

I have been giving this a lot of thought. Certainly backups are part of the preparation for a business to be ready for a potential emergency, as in the case of a computer crash which the client just experienced.

Having a good backup strategy is a good start. However, we may want to go even further. In space, many systems are redundant since there is no way to get things fixed quickly. When I used to work at GE Space Division, the saying was "It is hard to find a ladder to reach a satellite if something breaks down."

Of course NASA has much more of a budget than most of us will ever have, so we cannot justify going that far. But the question is how far do we want to go?

It might make sense for a critical employee to have two computers, both validated, and both loaded with the software needed, and both able to access the "data" on a file server. Both of these computers are ready to go. If one goes down, the employee uses the other until the first one is fixed or if necessary replaced.

A key point is that this planning takes place ahead of time. The proper analysis is made when we have the time to think about it. When we implement the redundant systems (and the necessary backups), we make sure everything is working (including file recovery).

Then, when we are in the middle of a critical project, and we have a crash, we implement our "switch over" plan, and continue working.

The hard question is how much insurance is enough. No real easy answer for that one!

Welcome to Mousley Consulting's blog

Hi all,

This is our first posting. I appreciate your time to read this.

Over the years (16 to be exact) we have been providing contract programming services for the biotechnology and pharmaceutical industry. We have programmed in a number of different languages ranging from Oracle PL/SQL to Microsoft .NET. We have covered a complete range of applications for data management departments including setting up Clinicial Data Management Ssystems (CDMS) and Electronic Data Capture (EDC) applications, programming Edit Checks, programming lab normal range applications, programming safety systems (eSafety Net and Clintrace), and many others.

We also have been involved in the metal industry for many years as my father owns Atlas Bronze Corporation.

Lately we have expanded into the financial arena. We have been involved with several companies attempting to raise money. One of my favorites at the moment is a Brew Pub in Hanover, PA.

We look forward to serving you an a number of different ways. Please email me at kirk@mousleyconsulting.com if you are interested in learning more.

Kirk