Escape Velocity

When an IT project has been delivered sometimes the hardest thing to do is to get out. There usually are post go live defects and issues to deal with. To make sure that you can turn over the delivered application and close out the project you should develop a transition plan prior to go live. This plan should detail how long the warranty period is, who takes over support, what documentation is needed fore turnover etc. Having this plan will help you achieve escape velocity.

1,2,3,4 what are we counting for

This week the tip of the week on the Project Right Track web site, http://projectrighttrack.com/support.html discusses defect rating and prioritization for IT projects. My premise is that we spend too much time worrying about categories then actually figuring out what is most important to fix and fixing it. My tweets and this blog will echo that theme.

Most organizations use a defect rating scale of 1 to 4 or 5 where 1 is most critical and 4 or 5 is a minor or cosmetic issue. In all of my years of managing projects I am not sure I have ever seen a defect rated a 4 or 5 fixed. I'm certain a few have, probably by accident. So why do we rate them. The rating systems are used to help us determiner which are the most important or impactful defects that must be fixed.

Rather than rate theses defects 1 - 4 would it be better to identify the top 5 or 10 and work on those. When those are done, 5 or 10 more could be selected and so on.

By doing this, you are focusing resources on the most critical items and saving a bunch of counting.

"Less is More"

When you validate for a go live weekend make sure there are clear definitions as too how much needs to be done for validation. Today during go live the users processed a lot of work in a short period of time. Unfortunately the validation of each item takes a lot longer than the entry. Thus they could not validate everything in time to make the go / no go checkpoint. We are not sure if we have a problem because we really can't tell what should have worked because of the sheer volume done.  It is critically important that you plan how much work will make a good validation set and stick to it. More is not always good.

Listening is the best communication method

During go live weekends there will be issues found and some defects. When the users who are validating find these be careful not to go into explain mode. Listen to what they say and ask questions about the issue. Is it critical? What is the business impact? Is there a work around? Did this issue exist in production? The more you ask and listen the better the overall communication is which will result in a better outcome.

"Clowns to the left of me, Jokers to the right ...."

One of the most critical items of any go live is making sure you have the right resources for each task including validation. For example tonight we had the director of accounting and a senior underwriter look at policy output and invoices form the first validation cycle. They could very quickly spot issues that a developer or QA resource may not. So when you plan a go live event look at the tasks and schedule and make sure each has the key person or persons assigned. Then go back and look at implied items such as print jobs etc and make the right resources are also available.

Once More Into The Breach

So for those that follow this blog we are in the middle of our second attempt at a go live for 4 major projects. We incorporated lessons learned from the first go live weekend so what was a good plan before is even better with better timings. We are running ahead of schedule so one of the things we have to watch out for is to make sure people who thought their task was going to occur later are available when we are ready for them. Thus we are updating our status line more frequently and will call people when we kick off the next task which takes three hours to let them know to be ready to start earlier.