Navigate / search

Welcome! Take a Look Around!

Project Coaching Center (PCC) is a place for people who are looking for coaching on the stickiest most intractable project problems they’ve ever faced. Problems that seem to require skills and experience beyond their current training or certifications. PCC is also for people who simply want a tip, hint, or insight to add to their toolkit for project success. Maybe your project is going well and you want to share your experience with others or ask a question to get some feedback. You can find some answers, share your experience, ask a question, and get personalized coaching at PCC.

  • user

    One-on-One Coaching

    One-on-one coaching is available with any of our consultants for some personalized and specific help with your project concerns. More

  • customers

    Team Coaching

    We offer group project coaching sessions to teams and will facilitate discussions and offer specific help with your project or team needs. More

  • hire-me


    For those rare times when your project really needs it. Check out our on-site Project Consulting Services More

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

3 Reasons Why ERP Projects Need the President’s Involvement

By Wayne Strider

In a previous post, “A Unique Role for the President in ERP Projects”, I suggested that an organization’s president has a unique role in ERP projects and gave examples of what the president can do that no one else can.

In this post I want to tell you why it is so important that the president be actively involved in an ERP project.  Here are three reasons:

1. ERP Projects Are Risky

ERP projects are not like most other IT projects. They tend to be highly visible. Internally they can affect how employees do their work in almost every part of the organization or institution. Externally they can be media magnets. They typically have very large price tags.  They have a track record of troubled implementations. They deeply touch the operations that you depend on to run your business. If an ERP project goes badly there are significant risks:

• The ability to achieve your mission and strategy can be jeopardized if you are counting on your ERP system to increase your competitiveness and it doesn’t work as expected.

• The ability to run your day-to-day business can be compromised if your ERP produces errors in payroll, accounting, purchasing, accounts receivable and so on. What would it cost your organization per hour or day to have any of these functions inoperable or producing errors?  Hershey Foods several years ago suffered order processing and shipping problems during the Halloween and pre-Christmas sales periods due to a glitch in their new $112 million ERP. Third quarter sales were down 12.4% or $151 million. Share price fell 27% from the year high. (Source:

• There could be an uprising among staff who don’t want to change how they do their work.

• Your organization could get a black eye in the press.

• A ton of money could be spent with little or no value realized.

• Your president’s career could suffer a setback.

2. You Can’t Just Leave It To The IT Department

The IT department can handle getting the technology up and running. That’s what they do best. But, most IT departments typically do not possess the skills or experience to handle the political, organizational, and human change management issues that are inevitable with ERP projects. When ERP projects go badly it is almost never because of  technical issues or lack of technical skills.

3. You Can’t Just Leave It To The Project Governance Structure

Many ERP projects have a governance structure that includes executive sponsors (i.e., direct reports to the president) to handle decisions that cross organizational boundaries or that are outside the authority of the project manager. The president may not be included in the governance structure. The idea is that executive sponsors will handle the most difficult enterprise decisions; and therefore, not bother the president. Even under the best of circumstances this governance structure can fail to keep the project on track. Here are three reasons why:

• It is human nature not to want to be the bearer of bad news. The project staff, team leads, project manager, project office, and possibly even the CIO do not always reveal the most serious problems to the governance structure. They have so much hope and belief in themselves that they keep thinking they can fix the problems. However, this belief can become a trap. They can lose their objectivity. They can lose their ability to notice they need help.

• Executive sponsors often don’t know which questions to ask of the project leaders or how to interpret their answers. Just because they are executives does not mean they know how to oversee an enterprise IT project. What they don’t know about the project can become a trap. They can lose their ability to understand the significance of the information they’re given and of the information that they’re not given.

• Presidents are too busy to get involved in all the details of an ERP. Many do not want to be seen as micro managing the executive sponsors nor give the appearance of not trusting their IT staffs. This belief can become a trap. They can become isolated. They can lose their ability to know what is really going on with the project. Yet boards still hold presidents responsible and accountable for the significant dollars these projects consume.

Notice how these three traps can conspire to keep anyone from noticing the project is in trouble, and therefore asking for help. ERP projects get into trouble gradually over time, not all of a sudden overnight–although when the top finally blows off, it might seem like it happened overnight.



facebook like