jump to navigation

The Conference Room Pilot – Change Management 04/30/2011

Posted by TBoehm30 in Project Management.
Tags: , , , , ,
1 comment so far

Someone once said “If you stand still you die” (or something like that).  People need change – both in our private lives and our business life.  Some people crave change, while others avoid it like the plague.

The other day before work, I thought I heard thunder.  I went downstairs and asked my wife if it was beginning to storm, or was she moving furniture.  My wife loves to change the house around.  She’s been doing it since she was old enough to walk.  Her parents talk about a tiny little girl pushing a giant dresser around the room inch by inch.  This morning she had switched our living room and our dining room.  She had already pushed the dining room table into the other room – that was what I thought was thunder.

I may not be much of a mover, but after a bit of work I realized that she had a great idea.  The new dining room would allow us to seat more people in one room; we had family coming over for dinner the next week and could use the space.  I wasn’t originally thrilled with the idea, but now I really love it.  Next, she’ll want me to paint the new living room.  I’m not looking forward to a weekend of painting, but again, she’ll be right and it will look great.  (shh, don’t tell her I said she was right.)

Employees, who are like my wife, will really enjoy learning about a new software system.  They will be active participants, learn what to do, and help others.  Their energy can be contagious, helping others to feel good about the changes that are coming.

Others, however, will fear the change.  They will worry about not being able to handle the new aspects of their job or worse, their job going away.  They will fight the change with arguments that range from the simple to complex, from obvious to the outrageous.  It is important not to scare those people away, but to work with them in a way to get them to accept the change and work with you and the new system.

I once worked with a client that had a couple of people like that.  They stored their documents in Word and had an entire notebook dedicated to the rules on changing them.  These documents were very important to their processes and kept the company running smoothly.  Changes to the documents had to be approved at several levels and the changes themselves had to be documented.

The new software could dynamically create the documents to be printed, eliminating most of the procedures in the big notebook.  This was scary to them.  The FDA audits the company every so often and required real quality control.  What would the FDA say to a new system?

 How could they prove that the system still printed out the right documents?  Would it even be possible to prove the validity of a new system?  How much testing were we signing up for to make sure that the new software did what it was supposed to do?  How could they control the changes to the documents if they weren’t stored in a central location?  All these questions needed to be studied in detail to provide a good answer to scared employees. 

They needed to see that the new system would make their job easier and more fun.  It would take some work to get there, but the work would be worth it.  They would have to put in some extra effort to get to the point where the new system could take over, but at that point they would be able to put their energy into innovation instead of following rules.

The Conference Room Pilot is a great way to slowly bring people like that around to a new way of thinking.  I didn’t tell them outright that we were going to do it my way.  I assured them the paperwork could stay the same until they were comfortable with the new system.  We walked through the new functionality numerous times.  We created documents from the new system, just to show them how it worked.  We created the new procedures so that when they changed their mind, printing the new documents could easily be added.  Eventually they realized that the new system would only improve their business.

Change Management is an art.  People who don’t like change or are afraid of change exist everywhere.  They are still valuable employees and an important part of the company.  Fear is a legitimate feeling that lets us know danger is approaching.  A new software system can be a scary project to see coming.  It is important to be ready for change management.

Every project manager needs to recognize the people who are worried and have a plan to deal with them.  They aren’t going away and you don’t want them fighting you at every step.  There is plenty of information on the internet about how to prepare for change management.  Just do a Google search on Change Management to get some very good frameworks.  Include lots of information in the Pilot; do a lot of explaining to ease people into the project.  Address their fears head on or slowly show them the advantages of the new system.

Have you dealt with people afraid of change?  Tell me your stories, what they were afraid of, and how you handled it.

Not everyone accepts change at the same pace.  If you take the time to bring everyone into your camp, they will all realize – just like you do – that it’s a global world out there and Technology makes it happen.

Advertisements

Conference Room Pilot Techniques – The Dry Run 01/25/2011

Posted by TBoehm30 in Project Management.
Tags: , , , , , , ,
1 comment so far

The final practice run through that you perform when getting ready to implement your new software system is called the Dry Run.  This is when you make sure that there are going to be no surprises.  You make sure that you’ve crossed all your ‘T’s and dotted all the ‘I’s.  Everybody knows what they are doing and when to do it.

 Order Matters

The order in which you proceed could make a big difference to the success of the project.  I recently practiced a process to load inventory into a system that already had work orders loaded.  Because the system was supposed to automatically allocate inventory when work orders are created, the inventory was allocated as it was loaded.  This was not what the client wanted.  Because they had only practiced loading inventory and work orders separately, they never saw the interaction of the two processes until I helped them test.  We determined that we always needed to load inventory first to avoid the issue.  Later, we found the checkbox to turn off the auto-allocation during the load.

Had they never done a full Dry Run, they might not have seen this problem until it was too late.  Once the data gets loaded into a Production environment it gets difficult to remove without starting over completely.

Practice

The people involved in the implementation need to have hands on practice performing their responsibilities.  They need to have demonstrated to the team that they know what they are doing.  One time I watched a lady using the new system who had no idea what she was doing.  She had previously reported practicing with the system and putting the time in to learn her job.  The difference at the Dry Run was that nothing was scripted out for her.  She had to figure out where to go to find work to do; no one had written down the order numbers for her to easily find.

The important thing about practicing for a go-live on a new software system is to demonstrate your knowledge.  You need to be able to perform under pressure while others watch you.

Is it fully setup?

There are numerous parameters and setup data that will need to be transferred from the test environment into Production.  You need to make sure that you understand that process, that you’ve covered all the parameters or setup data, and that those items have been tested.  A full Dry Run will ensure that the entire process to copy data has been practiced and can be done again successfully at go-live.

Balance the Reports

The Dry Run is a time when you should run actual data through the new system.  You can compare reports from your old system with the reports from the new system.  Can you make them balance to the penny?  Does the data go to the general ledger correctly?  Does the new system handle the one-off exceptions correctly?

Communication

Management should be involved in the Dry Run.  You can prove to them that the project will be a success.  You can gain the confidence of management. 

You probably worked with a core team on the project.  That core team should know all about the new software system.  If there are others who need to understand or learn about the system, then they can be included as well.  You may have scheduled training for another time, but the Dry Run is a time when all modules of the software should be shown on the big screen.

What else can go wrong?

There are far too many ways that an IT project can go wrong.  The Dry Run is the final opportunity to prove that you have covered all the risks.  Try to think about what could go wrong and mitigate the problems.

Have your Pilots gone well, or have they spiraled out of control?  I’d love to hear your stories – especially if you understand that it’s a global world out there and Technology makes it happen.

Spin Off 07/23/2010

Posted by TBoehm30 in Project Management.
Tags: , , , , , , , ,
add a comment

How does a company chop it’s IT in order to spin off and sell a part of itself?

I just read an excellent article by Mike Gorsage from Tatum about Integrating IT for Mergers and Acquisitions.  In the second half of the article he talks about “Planning for Separation.”

 This got me thinking about when I was consulting with Agilent as they were getting ready to split the company and sell part of it to Philips.  Agilent had just recently split from HP and some of the IT was still, unofficially, shared.  While HP and Agilent were two different companies, there was a shared culture that allowed people to communicate easily.  People at Agilent had come from HP and were comfortable with how things worked there.  Now some of them were being ‘sold’ to Philips and it had to change.

 Agilent had to figure out what IT the new company would take with it.  Some hardware and software would have to be duplicated, some would have to be given, and some would not be part of the sale.  They had to figure out the same thing with the IT team; however it is much more difficult to duplicate a person.

 I was working on their CRM system for the call center dealing with medical machinery.  HP/Agilent (now Philips) produced monitor type equipment for hospitals and doctors.  When the equipment had problems, they called the response center in Atlanta.  The call center would specifically be part of the sale to Philips.

 The CRM system, Clarify (now owned by Amdocs), was highly integrated with the back office system.  Corporate Agilent decided that the back office system would not be part of the sale.  Since Philips and Agilent, along with HP, are competitors in some arenas, the new company could have no access to proprietary data.

 That meant we had to get all of our data off of the old system, into a new system on a very tight timeline.  We had to update our CRM system to integrate with SAP instead of the old HP system.  With the help of some very smart people, we got the CRM system up to speed within our timeline and on budget.  We figured out how to download master data from SAP: the customers, contacts, products, and contracts.  We figured out how to send back to SAP the data it needed for tracking, billing, etc. 

 During the building move we managed to move all of the hardware over the weekend, so barely anyone knew it happened.  The call center is a 24 by 7 operation, so it had to be done carefully and quickly.

 The biggest problem turned out to be migrating data from the back office system to the new SAP system.  The contracts in the legacy system were confusing, not standardized, and big.  Agilent had a large team of people who came up with a plan to pull the data, clean it up, and then put it into SAP.  It would take weeks of processing the data after it was pulled, to clean it up enough to get into SAP.

 Agilent set up the deadline of when to be out of their system.  If the new company missed that deadline and needed continued access for another month it would cost Philips a lot of money.  We missed that deadline and had to extend.  Agilent doubled their fee the next month and would have doubled it again had we needed another month.

 By that time, I suppose, someone decided enough was enough, and called it done.  We had enough data to proceed and make it work.  Since I was not involved directly with old back end system, I have no idea what data we lost.  I can only imagine it was significant.

 With the new company complete, we worked on better integration with SAP, the politics of the new culture, and improving the call center.  Philips had bought several medical companies that would join us and we had to integrate them next.

 Most of the companies’ call centers were moved into our building and so we eventually shared the CRM system with them all.  We shared the phone system, and the other infrastructure that allowed us connectivity to the internet, intranet, and each other.

 Philips wanted everyone to use SAP in the call center.  We quickly did benchmarks and comparisons to show corporate how much extra it would cost to get rid of the current CRM system.  They acquiesced, at least temporarily, to allow the legacy system.  Their idea was still to get rid of it, and that theme was seen in numerous meetings.  We managed to continue the use of Clarify, even against the wishes of some big-wigs at Philips IT.  Eventually it was expanded to other countries around the world.

 The thing that Philips did right was allow the best technology to continue being used, and even invested in its future.  While they had alternate plans, the old systems worked well and could not easily be changed so they didn’t change it.  Their alternate plans were shelved, and new plans created to better the company as a whole.

 Philips had the people who understand it’s a global world out there and Technology makes it happen.

Lessons Learned 06/17/2010

Posted by TBoehm30 in Project Management.
Tags: , , , , ,
add a comment

I recently participated in a meeting to discuss the Lessons Learned during the recent ERP implementation.  Many projects skip this vital step because they don’t have time, or after a successful implementation, what’s the point?  This meeting turned out much better than I thought it would, and we actually documented a list of items to review for the next projects.

The project ended successfully, so we didn’t have to point fingers blaming anyone.  I have been to plenty of those types of meetings where nothing gets done except making people feel bad.  When it was my turn to talk, and I suggested improvements to the way we prepared for the Conference Room Pilots or Dry Run, I prefaced it by reiterating the successful nature of the project.   I couldn’t pin blame on lack of preparation because in the end everyone was prepared enough.

People did listen to the suggestions.  We still have 2 Business Units that will go live on the new ERP system, and they now have on idea of what issues they need to review to improve their chances of success.

The project manager for the software vendor attended the meeting.  During the project, there were times that he became defensive about his software.  He would come up with ‘reasons’ why it wasn’t their fault, or get upset with us about our tone.  During this meeting, however, he listened to everything in the spirit of constructive criticism.  He didn’t get too defensive on the phone and said that he would take our comments to an appropriate resource.  He responded in email with extra documentation that could have helped during the project (we actually had it, but some people didn’t know that), and will definitely help the last 2 Business Units in their project.

We spent some of the time patting ourselves on the back with the things that went well.  We didn’t just talk about the things on the project that went poorly or could have been done better.  We put in extra hours over the weekend before go-live and were totally prepared for that work.  Talking about that work and reminding everyone how great they did felt so much better than focusing only on the problems.  Reviewing the items that went well made everyone feel good about the work they did and prevented deep depression over our faults.

We concentrated on the actions we could have taken, or will take next time, to do better.  We tried to direct the discussions toward constructive criticisms instead of blame or complaints.  When the conversation turned more negative we directed it toward a more positive note.

I think everyone walked away from the meeting feeling good.  We documented a full list of items to keep in mind for the next projects.  Lessons were learned, and they will stick with those who learned them.

Putting in new technology is not easy.  We need to make sure we get better at it by improving each time we do a project.

For your next project, make sure to schedule time for the Lessons Learned meeting.  It will improve future projects, and people will be more comfortable with taking on the responsibilities of the project. 

While we didn’t create a list of questions beforehand, that would have been a good idea.  Send out a list of open-ended questions to prepare people for the meeting.  “What worked best?” “What could have worked better?” “What prevented goals from being achieved?” etc.

If you need to include many people in the Lessons Learned process, then send out a survey.  This could be done over email if you properly include everyone, and make sure that you follow up with summaries.

You may know it, but others may not, so spread the word: It’s a global world out there and Technology makes it happen.

Keeping the Meeting Going 05/07/2010

Posted by TBoehm30 in Project Management.
Tags: , , ,
3 comments

My client recently asked if we needed to keep up the weekly PMO meeting. This is a company that has 4 Business Units in different states of the U.S. I explained that the only way to know what is going on across the company, and to ask relevant questions of other leaders is to have a regular meeting.

It is a very normal feeling to be annoyed with regular communication meetings, especially when there are no important projects to discuss. Most people complain about the silly meetings they have to go to, the ridiculous discussions, and the cost to the company of having all those people there. Of course they are busy and could be more productive on their own, in their office or cubicle.

Good Meetings
Sometimes, however, meetings are important. Meetings that have a competent person running them, have a set agenda, and don’t run over can be very productive.

  • At the start of a project, meetings are essential for brainstorming, gathering requirements, forming the team, and setting a schedule.
  • Milestone meetings can be very beneficial to coordinate important steps in a project. The meeting could also be helpful in letting everyone know the status of a project.
  • Meetings may increase right before and during the Go-Live of a project. This keeps everyone on task, and lets them know the importance of their individual work.
  • Many managers like their group to have regularly scheduled meetings. These keep everyone informed of what is going on, and can bond people together forming a team.

In the case of my client, the meetings are absolutely necessary to keep the lines of communication open and to know what is going on at diverse locations. Sometimes we needed to make decisions for one Unit that would affect everyone. Sometimes one Unit would bring up an issue that another Unit realized should be happening to them too. Problems are discussed that can be solved by people in a different Business Unit.

The most important item in the list above is communication. Everyone at the company doesn’t need to know every little detail about what is going on everywhere. It is nice, though, when most people have a broad idea of what is happening. It keeps them involved, makes them feel like part of the team, and improves overall productivity.

Bad Meetings
The reason that most people get annoyed with meetings is that they feel nothing gets accomplished. One of the biggest reasons people stay happy at their jobs is the feeling of accomplishment. There’s nothing so frustrating as having important work waiting at your desk while you are wasting time in a fruitless meeting.

I have been to meetings where everyone says the exact same thing that they said last week. While doing support, we had weekly team meetings. Many times, when nothing big was going on, we could have just replayed the previous week’s meeting.

Once, I had to monitor a few meetings with an off-site development group. The manager of that group would point to the people in his group and say things like “last week you were 85% done, now what are you?” They would come back with silly statements like “well, I’m now about 90% done, but the 10% that is left will take me a few weeks longer than expected.” I would sit there thinking ‘Really! Does it matter how many small percentage numbers they completed this week?’ I wanted to talk about issues, about what was blocking the project, about how to get it done.

I’ve also done the meeting where I am just filling in people who don’t know what is going on, and probably never really needed to know either. They were told to get involved, and so it was my job to fill them in. I knew it was a waste of time, they knew it was a waste of time, but just in case that one small bit of important information would come to the surface, we had to have the meeting.

I’ve been to meetings where I was invited, just in case someone asked a question about my segment of the project. The meeting didn’t involve me, didn’t need me, and shouldn’t have required me. No one actually asked about my involvement and I got paid to waste my time.

Everyone has been to that meeting that was hijacked by someone else’s agenda. Nothing important got done because some blow-hard had to keep taking about his own project. Someone wanted to show us how smart she was, and just couldn’t stop talking long enough to let anyone else have their say.

How to Decide
To all of you that are about to call a meeting, I ask you to think about it first. Will this meeting fulfill a specific purpose? Does anyone have anything important to say? Has anything changed since the last meeting?

Create an agenda. Start and end the meeting on time. Don’t let people divert the topic of conversation too far from the agenda.

I told my client that communication is very important. The Business Units in different states need to talk every so often so that problems can be worked on together, and decisions are made that are for the good of the whole company. They won’t need a weekly meeting once I’m gone, but they should have it every so often. I am sure that they can find someone almost as good as me to lead the meetings.

They just need to find someone who knows that it’s a global world out there and Technology makes it happen.