I remember one project where my team rolled out a new enhancement on a weekend and had key users there to do some high-level tests.  The implementation was flawless. The high fiving and hugging that ensued reminded me of a team that just won the World Cup. I think one developer ripped his shirt off and slid down the hall on his knees! On Monday another BA and I went walking around the user community to be available for questions.  There was silence.  The reason was partly due to the users not using the new system and sticking with their Excel spreadsheets.  Why?  They were not comfortable with the new system and still had tight deadlines to meet.  There was no time to get accustomed to the new system right away. It ended up they were never going to have time to feel comfortable with the new system.  What did we miss? We did not give enough attention to the transition needs or transition requirements. 

Much of the focus around requirements is eliciting, analyzing, and communicating the project objectives and product requirements.  These are the requirements to build a solution.  Where many teams spend too little time is with specifying transition requirements.  These are the requirements that address how you make a smooth transition to the production environment once the solution is built. 

There are two major areas that impact transition.  The first is the impact to applications and the second is the impact to the people.  Let's take a look at these two areas where I see the business analysis professional playing a big role in helping ensure a smooth transition. 

The impact to applications

Within applications there are two components I want to highlight.  The first piece is data updates/conversion.  With the new application or enhancements being rolled out there may be one-time data updates needed.  On a recent CRM project one enhancement was to add fields to the contact record.  I made sure to ask the question if any of the fields needed to be populated when we move it to production.  This is different than having the default value of a field being set for every contact.  In this case we were splitting one field into three fields.  Depending on the value of the original field those three fields had to be populated a specific way.

The second is coordination with other applications that will be impacted.  If the new application you are moving into production integrates with other applications you need to coordinate roll-outs to ensure all applications are in sync. The worst thing that can happen is your team is high fiving while another user community is impacted negatively and can't use their current system any longer.

The Impact to the people

You have probably heard me say this before. Projects are for people. In the end you don't implement a project for a company.  It is for people within the company. And every project no matter how small or large is a change.  It impacts people. Deep down inside we really don't like change even if we ask for it all the time. With almost every implementation current processes that people perform are going to change.  How they do their work every day is impacted by the implementation of the projects you work on.  We have to work with the user community to gauge the impact and design an implementation or transition plan which will result in the least amount of disruption to people. 

I think it is safe to say most of us use MS Word.  If you made the transition to MS Word 2007 you know it took some time to get used to the new user interface (UI).  I like the new UI, but it took me longer to format a document the first few times I used it.  It was actually a little frustrating because I was in a rush. There are still some features I struggle to find.  This feeling is what your user community experiences every time you implement a new application or enhancements.

As the business analyst you get to know the environment and the people.  You need to help design a training plan for the user community, and help the team and business determine how the cutover will take place.  By cutover I mean will you go cold turkey and flip the switch on the new application and the old one is gone.  Or will you run both in parallel for a period of time. Or will a small pilot group use the new application for a period before rolling it out to the community at large. 

The goal is not to build something.  The goal is to build something that the users will use because it improves their work and in turn adds value to the company.  If you focus time on the transition needs, you increase the chances of having the project team and the user community jumping for joy.

All the best,

Kupe