jump to navigation

Building an ERP team 02/29/2012

Posted by TBoehm30 in ERP.
Tags: , , , , , , , ,
trackback

Half the team wanted to delay, half the team wanted to move forward with the existing schedule.  What could we do?  We didn’t want to make anybody so mad that they would quit the project, or worse yet, quit their job.  If the team as a whole couldn’t agree, who would stand up and be the bad guy to delay the project?

This was the dilemma I was in recently.  We were doing a dry run for the go-live of an ERP implementation.  Corporate was already using the system, as well as a few other locations.  This last team to join the system was not ready; they were way behind schedule.  However, they didn’t understand what they were missing.  They felt like they had more important projects to concentrate on and the ERP project was getting in their way.  They just wanted it to be over; put them on the live system and work out the bugs later.

All of the meetings with this company so far had been as a team.  We made positive decisions with everyone’s input where everyone could agree at the conclusion of the meeting.  The other locations had seen some setbacks, but everyone had seen the need for a delay or change in the project.  We had always been a solid team who understood the decisions made.

This was different.  The on-site team wanted to go-live, no matter the consequences.  There are always problems at go-live; we should just handle them as we get them.  So what if we didn’t understand all of the setup codes now, we can change them later when we figure them out.  All of the reports won’t be ready, but every group had needed new reports after go-live.

The problem, of course, was one of risk.  If this one group couldn’t close their accounting in a timely manner, corporate wouldn’t keep the books open just for them.  They had several other sites to think about, and they can close their books on time.  Closing the books quickly, each month, is important to a public company, and it is one of the reasons we were implementing the ERP system.

The on-site team thought that if something went extremely wrong, we could just figure out everything on paper.  They actually said that.  A multi-million dollar public company writing their monthly reports using paper and a calculator.  I can see it now.

The manager on-site wanted to know what problems would cause them to not be able to close the books at the end of the month.  If we could list out all the glitches, difficulties, snags, hitches, or complications, then they would just avoid those and be successful.  It was a great strategy for him.  We would come up with a list of problems and then if we missed one, the problem would not be his fault.  He wanted to put the blame on everyone else if there was a problem.  Let’s just go-live now and get this stupid project behind us.

The rest of us in the room wanted to delay the project.  Give them more time to figure out what is going on.  Extend the schedule so that they can keep the doors of the factory open, and still spend some quality time on the ERP project. 

The problem is that we needed to work as a team.  How do we come to an agreement when we are on completely different sides of the same coin?

We gave them another couple of weeks to ‘catch up’ on what had already been scheduled.  To their credit, they worked extremely hard to get it all done.  I was getting emails at 3 in the morning.  Unfortunately it was too little, too late.  When the new deadline passed we were at the exact same spot.  Most of us wanted to delay the project, but the team on-site didn’t understand why they couldn’t just proceed.

I actually practiced my bad-cop speech.  I stood in front of the mirror and explained why proceeding down this path was a bad idea.  When we came to go-live and had to give a thumbs-up thumbs-down vote in front of the CFO, I would have to vote thumbs-down.  That is what I would have said had we gotten to that point.

The director of IT beat me to it.  He said in plain language that the deadline was missed; it’s time to change the schedule.  Thank goodness.  Everyone agreed at that point, even if the on-site manager only agreed under protest.

Going forward, I need to get them to understand that their job is to convince me that they are ready.  It isn’t just to go through the steps needed to finish the project.  There are people who are going to evaluate their readiness at the end of this project.  We will have help in deciding whether or not to go-live, based on their performance.  If they can understand that, then we have a shot at once again working as a team and getting the job done.

Anyone else have some fun stories about getting a team to work together?  Tell the world about the time you worked with a group to come to the conclusion that It’s a global world and Technology makes it happen.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: