If you go off trail, carry a machete or "He chose poorly"

All thorugh the weekend everything was going well until Sunday morning when we discovered data issues. The cause was identified quickly and a plan to fix the records was devised. However this scenario had never been tested or done before so we were winging it. Unortunately we needed to restore afile and chose the wrong one. This caused more issues and caused us to backout the changes.

Got Me Again

Conversion ran all night and was almost done when it stopped. Apparently we forgot to shut down the backups this morning. Fortunately only 250 records left and we can restart from there. "Missed it by That Much"

Beware the Old Data

Just had a scare. As we were looking at the conversion we saw some anomalies and thought we had a big issue. Turned out that the records in question were some of the oldest . After reviewing these we found that we did not have an issue. But it does bring up another good lesson for converting data. Always look at both the newest and oldest records to convert to identify differences so they can be addressed in the conversion programs. 

Conversion 101

So it is now 8 PM Sat on go live weekend. We have finished our configurations and setup and are now in the middle of data conversion. The cool thing about this one is that the developer from our vendor who is responsible for the conversion has worked with us to test the heck out of it. We have executed over 30 full or partial runs of the conversion routines and validated each one. The data we are converting dates back over 10 years so the extra testing has really helped fine tune the programs. To me, you can never test conversion enough.

Press on Regardless

So last night we were way ahead of schedule. Rather than waiting we kept moving forward. Today one of the tasks we had took longer but because we had kept going we are still ahead of schedule. On big implementations buying yourself some extra time is crucial.

I Love it When a Plan Comes Together

The fun thing about go live weekends is that no matter how much you plan you just don't know what will happen till you get going. So far we are doing very well and are ahead of schedule. So now we are looking at the plan  and figuring out what impact on the schedule will be. This includes getting people to arrive earlier that originally plan to do their tasks. Communication is so important during the weekend. This includes taht everybody involved must be accesible.

And off we go!

The project go live tasks are underway. As usual we have some people who want to go faster but for the most part we are staying on the plan. On all of these implementations staying on plan is important. If oyu get too far ahead of schedule you could muiss tasks or dependencies.

Sometimes the plan does come together

Here we go. 4 PM on Thursday before go live and all critical issues are resolved and we are a GO for the weekend implementation. Today we scrambled to fix the check formats but they are done and the user lead is satisfied that we are ready to rock. Tomorrow morning will be spent making sure the legacy system tasks are all done and that the existing prod system is also free of any pended items. Check back all weekend for regular from the trenches updates.

If you are not sure, pick up the phone!

Here we are 3 days before the start of go live activities and once again a seemingly straight forward task has caused issues. We are upgrading the claims system to support another line of business. This line uses different checks than the workers comp product already on the claim system. Because of this and other requirements the vendor was creating a new check print function that will support multi drawer printing. A couple of weeks ago there was some concern that the vendor was not understanding the check layout so I sent a sample from the existing system. The sample had a top part and a bottom part. I was concerned with the top part which is the actual check. However when the vendor got the sample they took the whole thing as the requirement even though in the past our user said that the bottom items were not needed. This of course caused confusion and apparently extra work from the vendor. Now I will take responsibility for part of the confusion and have already told the vendor this. However, when the vendor originally got the sample and saw the extra items on the bottom, why did they not just call and get clarification.

This is the lesson from today. Yes we need to be clear when we send requirements to  the developer but if the item sent is different than what was discussed, they should call first and get clarification. This should be true throughout any project. If something changes that you are not sure of, pick up the phone and ask.Fortunately this incident should not cause us to miss the go live but it was a distraction that we did not need.

3 Days and Counting

So here we go. The project go live is this weekend. With Monday being MLK day we have three work days to finish getting ready and wrap up the final tasks! This week we will have additional training for the users. They had class last week but this week we will have one on one sessions to allow them to ask questions and go through particular scenarios. Our biggest task is to get the final setup for printing claims checks in place and tested. We are behind on this but the vendor has finished testing at their shop and we will start testing tomorrow.

"No, No Way, and No that is stupid"

We are one week from go live and had the Go No Go meeting with the users, execs etc today. Right now we are a go!. The funny thing today was that 30 minutes before the meeting I went to my key user and asked her if she had any issues to raise. She said no. The truth is she did and she raised them during the meeting which at first caught me by surprise. Once I got past that surprise we just got busy and made sure her issues were addressed and resolved. One of the issues she raised had to do with not being able to view comments that were converted from another system This surprised us as we could see the comments in the database. What had happened was that during training the lead user made a statement that they only wanted to see general notes so the instructor who also handles security set up changed the security profile. Thus the converted comments would not display. This has been fixed but it does lead to my title. At this point in the project had the instructor asked me if the change was OK I would have immediately said NO. If she asked again I would have said NO WAY. If she asked a third time I think you can figure out what I would say. This may seem silly to some but in reality it is critically important. At this late stage any change, no matter how small can lead to major problems. Thus all changes must be looked and reviewed carefully to make sure only the most critical are made.

Training Day

For the next two days we will be training the users on the application. The company has one training room so we are training a week earlier as that is when we could get the facility. To help the new users be ready for go live the following week we will conduct one on one training sessions next week. This will help the new users solidify what they learned in class.

"Icebound"

A good chunk of NC businesses are closed today due to the icy conditions on the roads and cold temperatures. Throughout the south people everywhere are stuck at home because of this mess. With technology many of us can work remotely which is what I am doing today. The3re are some people however that don't have the best remote access and they are having trouble connecting to the network to get their tasks done.

This brings up a very important point for the go live weekend (Which starts in 7 work days) With our vendor based in SC some of the vendor staff will be on site but many will also be remote either from their offices or home. Will they have good connections when we need them. Do they have a back up? For example if my modem cable connection does dead I can use my 3G wireless card. We need to be sure these questions get asked and answered before the go live starts and  find a critical resource is electronically MIA. We have already arranged for many critical resources to be on site.

So for any go live event ask the following:

• Who are the critical resources and where will they be?
• Should everybody come into the office?
• Do we have primary and secondary phone numbers for every resource? What about secondary emails (Sometimes believe it or not it is easier to get through on Yahoo mail than the company email)
• Are there back up resources identified for critical tasks?

8 days to go live

With 8 days to go the hope is that the the project is ready for go live. Code should be locked down by now or very close. All functions have been tested and all major defects resolved. Unfortunately many IT projects get to this point and have one or more significant errors that the team is frantically trying to fix. The question then is how long should this continue before we throw in the towel and reschedule the go live. There is no single answer to this question. In reality the answer depends on many factors including:

• Is the cause of the defect known and a fix imminent?
• What is the risk of going live vs. the risk of delay?
• What is the real and potential cost of the delay?
• Can the company be fined if the project is delayed?
• What bad thing happens if you go live and there is a major issue?
•  How much risk can the company tolerate?
• How much manual work is introduced if part of the application is not functional?
• Can data be corrupted?

I have heard the mantra from many executives that we will not go live with major defects. This mantra does not hold true because of the questions above. Instead of coming up with an arbitrary answer, look at the project and answer the above questions. Doing so will help you decide when to charge ahead and when not to be the Light Brigade.

Go Live is Tough Enough but did it have to snow

For the record my client is based in Raleigh, NC so snow ,sleet, or ice can be a disaster here. 9 days before go live and we are expecting all of the above starting this afternoon! So to make sure we stay on track we are already invoking contingency options for training, travel etc. Our vendor is based in SC which already has been hit so we are communicating with them and coming up with optional plans to deal with this weather event. This illustrates a very important part of go live planning, cancellation due to weather. No matter where you are at you can be faced with a weather issue or other calamity that may delay go live. For any go live plan you should include:

•  Always have an alternative date established in advance so people know what the contingency is.
• Criteria by which a go live would be cancelled defined
• Cut off times and dates to make decisions
• Communication plan

End of the week - go live is 2 weeks away

Actually we have 9 business days as the 17th is a holiday. Today we continued final UAT and review of conversion records. At the end of the day the project team and I did a review of what we got done and what we need to do early next week. I also met with our lead user resource to get her input. She stated she was a bit uncomfortable because some of the code tables were not loaded fully. This is actually good input because if she is concerned her staff will be also if we don't get these fixed. Fortunately these will be easy to fix and will be done by Monday. The lesson here is that at this juncture don't be afraid to ask for honest input and if it is negative find out why and what is needed to fix it. All things are important at this point!

Even the little things count now

11 days to go live and the project overall is in good shape. Today during testing we found a few security items and code configurations that were out of whack and will get those fixed for tomorrow. We have to be careful though to not treat these "little" things as little things this late in the project. With business users doing the UAT even these little issues can cause them to think the application is not fully ready. Thus as these things do occur the project team is jumping on them and getting them fixed as quickly as possible. Training will occur next week for all of the users so we must get to a stable state.

Go Live T - 12 days. Managing Dependencies

As the project gets closer to go live managing dependencies becomes a frequent and critical task for any project team. On our project we are dependant on another project to migrate our data to a new platform before we can convert to our system. We have somebody from our team spot checking the migrated data in the test system before and after we run our conversion to make sure the migrate data is correct.

13 Business Days to Go Live

The project I am on is going live on 1/24. It is a update to a claims system to support another line of business and includes a data conversion. I make the distinction between business days and days on the project as the work schedule is based on work days which should include contingency time. Weekends are not contingency but emergency time only. The only weekend that is planned as work time is the go live weekend which we already have planned out and are now just tweaking the start and end times. I will be blogging about this project and getting ready for go live regularly over the next 3 weeks. I hope you find this useful for your project planning.