Navigate / search

A Framework for Project Launch Decisions: To Go or Not to Go Live

Go, Wait or Stop Light

By Eileen Strider

Although everyone knows that the Affordable Care Act (Obamacare) system was not ready for prime time on the October 1 launch date, does anyone really know how the decision was made to go-live? Was it a conscious decision with full consideration of the readiness of the system or a de facto decision when October 1 arrived?  And closer to home, do you know how your project will decide if it’s ready to go-live when the planned go-live date arrives?

My project and IT management experience is that most people don’t believe that they could actually say “No, the system is not ready and should not go live on the scheduled date.”  Here are just a few reasons why:

–       I’ll be the only one to say no.

–       No one will listen to me anyway.

–       I’ll be blamed for the project’s failure.

–       I’ll be labeled “Not a Team Player”.

–       I don’t have the courage to say no.

Any or all of these may actually happen. If you watched the congressional hearings, you saw lots of finger-pointing and heard lots of blaming from all parties involved; none of which fixes the system problems.

You can avoid this scenario by using a straight-forward process for deciding to go live or not on the planned launch date.

Here are the steps in this process:

1. Establish Go-Live Criteria

Identify objective criteria that must be met for the project to successfully go live. Don’t say that everything must be complete; be very specific about what must absolutely be working properly at Go Live. Each project is unique, so your project’s criteria will be unique. Establish the criteria as soon as you know enough about the project to define success.  If you have a project charter, use it to identify success criteria. Add to the criteria when you know enough about what technically is needed for success. If you discover another success criteria later in the project, revise the criteria. Just don’t wait until the last minute to set the criteria.

The key to success on this step is involving the project’s business sponsor in this step.  The sponsor should approve the Go Live criteria and understand exactly how it will be used. Typically there are both functional and technical criteria identified. Depending on the nature of the project, there may also be regulatory and legal criteria.

Here are a few examples of typical go-live criteria, along with indicators for how you know that criteria have been met.

System Functionality: Critical parts of the system work as specified: Testing is the activity used to verify this criteria is met.  Specify exactly which testing must be completed such as user acceptance testing , performance tests in terms of response time, load tests, security tests, integration tests between the new system and legacy systems, data verification testing, etc.

Data Readiness: Data required to operate the system has been loaded and verified. If data conversion is involved, this has been completed and verified as accurate. Data conversion often requires a significant amount of data cleanup. If data in the new system is incomplete or inaccurate, a significant correction effort might be required after go-live. This can be extremely aggravating to users of the system. Report testing should be complete.

User Readiness: This may involve user training, new/revised business process training, user equipment, help screens, tutorials, documentation, etc.  Define exactly what must be complete, especially for critical users. By complete, I mean verifying that users have developed enough competency to use the system effectively and efficiently; not just that you’ve checked off that they attended training. If your users are the general public, be sure testing was performed by a sample of members of the public. Read more

Putting Yourself in the Picture

By Eileen Strider

Who could possibly be missing from your project? The least noticeable and most important person – you, all of you, your whole self, not just your brain.

How do I know this? Because I have ignored key parts of myself as a project manager. And yes, I am willing to admit it, here, publicly to you.

You might be thinking “Isn’t this self-serving and arrogant?” I say a resounding no. It is about giving your very best effort to your project, your client and your company. Yes, if your project is successful, hopefully you will be seen as a valuable contributor, but that’s not selfish or arrogant. That’s doing a good job.

What in the world am I talking about when I say “your whole self”? I mean using not only your head but also your body, five senses, sixth sense (intuition), your emotions, and your free will to manage and lead your project. I know this sounds crazy but I’m not making it up.  Speaking from personal experience, my project outcomes were always better when I used my whole self. Here are some ways you can use your whole self to help lead your project:

Your Body

Pay attention to information that your body is giving you. Your body is an important source of feedback about the project that often goes unrecognized and unacknowledged. Are you experiencing headaches, a stiff neck, colds and sinus infections, digestive problems, sleepless nights, etc.? These might be warning signs that your project is in trouble. If your stomach is hurting, it may not be the flu. It may be something is not right on your project. Ask yourself what is it about your project that you are desperately trying to ignore but that your body is telling you to notice? This is one of the parts of me that I tried to ignore for too long on a failing project.

Your Five Senses

Seeing and Hearing: Observe with a critical eye; that is, see what’s really happening on your project, especially what’s happening to you, your customers, your project team and your vendors. Go beyond reading status reports. When you attend project meetings, listen for what’s being said between the lines and notice how people appear when they are giving their status report or listening to issues being brought up. If you notice that someone’s words don’t match how they look, then something else may be going on. Ask if there is something more they would like to tell you.

Smelling: Read more

Working With The Smartest People on Earth

By Eileen Strider

“We are the smartest people on earth; if we can’t build it, why do we think someone else can?”

This is a quote from an RFP (Request for Proposal) we recently received. The organization was looking  for consulting assistance to evaluate, select and implement a software system. The organization will remain anonymous to protect their sacrosanct cultural belief and their reputation. For you see, this organization has already experienced a failed project; this is their second attempt.

You might be saying to yourself “I know this organization”….and you very well might. We have worked with several organizations who believed that they were the smartest people on earth. It’s really not that unusual.

If you were chosen to provide this consulting support, how would you go about assisting them in their project? Where would you focus your efforts? You might be tempted to point out to them the error of their ways on the previous project. Maybe you would try to convince the organization that they were not actually the smartest people on earth. You might try to help them find a software vendor who could prove they were smarter than the smartest people on earth. You have little to no chance of changing this cultural belief. So, good luck using these approaches.

Here’s another way to approach them. Try following their belief that they have the smartest people on earth in their organization and ask some questions that prepare them for their second attempt. Read more

Projects Take a Community….to Succeed and to Fail

By Eileen Strider

In the world of projects, organizations reward project managers for success and punish them for failure, as if the project manager was solely responsible for either. As a project manager, you know this perspective is both a trap and a myth. Projects don’t succeed or fail based only on the actions of the project manager.

A project manager’s skills are certainly important. Having project management expertise, training, communication skills, a good head on your shoulders and a healthy dose of courage are valuable assets. And if you have these, then you know the entire project community can either support or sink a project.

The people who directly work on the project are viewed as “The Project Team” with the project manager as their leader. The rest of the organization often thinks the project team does all the work while they kibitz. But the project manager has to manage a much larger community that the project team members who are doing day-to-day project work.

The community includes a much broader group of people than the “project team”: CEOs, vice presidents, directors, managers, supervisors, staff members, vendors, suppliers, implementation partners, consultants, contractors, boards of trustees, etc. Each contributes to the success or failure of a project.

Okay, so what am I talking about? Here are some real live examples from my personal experience.

Board of Trustees Contribution Example

The project schedule had slipped multiple times for numerous reasons. Each schedule extension led to increased implementation costs. Each time the schedule slipped, the project manager took a request for more funding to the Board of Trustees. Each time the Board approved more funding. By the time we were called in to review the project, the cost had increased 400%, the Board was upset with the project manager and was ready to sue the vendor and the implementation partner. When we asked them why they had approved each additional funding request, they realized they hadn’t asked the right questions and accepted their contribution to the project’s problems.

Executive Collusion Example

While reviewing a failing IT system project, we kept hearing about problems with employee data. Depending on how you accessed employee data in the new system, you could get up to three different addresses for the same employee. Digging a little deeper, we discovered that the VP of HR refused to have his staff use the new system’s employee identification numbers, because his HR staff complained about having to enter more characters than they were used to entering. So, the VP of Finance agreed with the VP of HR to customize the system. The customization basically broke the integration between the HR and Payroll systems and resulted in employee data being stored in three different locations with no integrity checks.

I could go on and on with examples. But you get the idea.

Protect Yourself Read more

facebook like