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

The Project Observer – What Do You See?

by Marie Benesh

In our most recent podcast, How To Know Your Project is in Trouble, we mentioned the role of observer. This is a person who is charged with looking at the project from a different perspective – from an observer point of view.

This doesn’t have to be a full-time role, and usually isn’t. It can be you, the project manager, who decides to sit back and observe the project and team without interjecting. Or it can be a shared role, something that everyone on the team takes on at one time or another.

But what are you looking for? What behaviors or indicators will give you more information than the words that people are speaking? Or what are the words you can listen for that might tell you something is amiss or that there is meaning and information under the words that are being spoken?

There are some obvious signals that most of you will be aware of:

  • Body language cues: in a meeting, a person sits with their arms crossed, doesn’t speak up during the meeting, and may look angry, disgusted, or “closed” to ideas and discussions going on in the meeting
  • Angry words or behavior from a team member; slamming doors or drawers, walking out of a meeting, raising his/her voice during a discussion
  • Isolation – this is when someone (or a sub-team) works in silence, does what they want to do and generally ignores anything else going on around them. This one can be a little tricky, as there are people who are just really good at staying out of the fray and are focused workers. Learn the difference.
  • Words that might indicate “more going on underneath” are: concerned, am not comfortable with, “whatever,” words of acceptance but with a different body language… Okay, (but with a sigh at the end).

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

Demonstrating a Culture Change

By Eileen Strider

You want to introduce a change into your project’s culture? How do you do this in a way that gives you some hope of success? Well,  no two organizations’ cultures are exactly alike. No two projects are exactly the same.  Because each culture change is unique, we can’t give you an out-of-the-box recipe. So we’ll give you two examples, followed by some general principles you can use. These principles can help you introduce a change in a way your organization can accept, is able to try and won’t kill with resistance.

This blog was written at the request of listeners to our podcast “Five Aspects of Culture That Can Impact Your Project”. Listen now on Blog Talk Radio

Let’s start with an example of how NOT to introduce a change. Then we’ll follow up with a successful example. And last but not least, give you some general principals for how to go about it.

A Bad Fit Example

A client asked us to help him interview candidates for a senior project management position in his organization. After each interview we gave him our feedback. One of the candidates looked great on paper. He had a track record as a successful project manager in the manufacturing industry. He had his PMP certification and Six Sigma Black Belt certification. When we interviewed him, he described how he would approach the job of improving the staff’s project management and quality by introducing project methodology, discipline and metrics to the organization. We had worked with this organization and knew that their culture did not value project management, measured very little and valued individual freedom over discipline. So, our interview feedback to the client was a recommendation not to hire him because although he was an experienced and skilled professional, his style and approach would not be a good fit for their organization. The client said “Well, we need to get more disciplined and skilled about projects here, so I’m going to hire him.” Well, he lasted 6 weeks on the job. The way he introduced change rubbed people the wrong way and they resisted. He found it hard to believe that his approach, which worked so well in manufacturing, didn’t work well in this organization. Notice that the person who hired him to change the organization did not have to change himself! The people who worked on projects did.

A Design to Fit Example

Here’s a successful example of introducing a culture change.  We were doing some work with an IT organization in higher education. The CIO asked us if we could help them understand how a project had failed to deliver the expected results, which they still needed. We recommended doing a project retrospective. We knew they did not have a project management culture and this would be their first retrospective. We also knew that they had difficulty working across functional departments and that there had been some blaming on this project. So, we met individually and privately with each person involved, asking them about their role on the project, explaining the retrospective process we would use, that no blaming would be involved and invited them to attend. This wasn’t just a courtesy. It was to allow us to hear about their experience on this project , what they hoped could happen in the retrospective and to increase their feeling of safety with us coming into the retrospective. We shortened and simplified our retrospective process to make this change a little easier for them to swallow. Read more

facebook like