jump to navigation

How IT Can Communicate with the Business 09/25/2009

Posted by tboehm30 in Success.
Tags: , , , , , , ,
add a comment

I always find it fascinating when people don’t understand tech-speak. Like any specialization, they have their own Three Letter Acronyms (TLAs), terms, and new names for their products. It is impossible to keep up with all of them, even if you are in IT yourself.

The key to communication is explaining those TLAs to business people, or asking for clarification from IT. If either side is deficient in these tasks, then poor understanding will result. This happens all the time and there are many reasons for this problem. Understanding the causes may help both sides to become better communicators.

On the IT side, people probably have had little training or experience in good communication. Their education and beginning job responsibilities have been to solve problems. If you are good at solving the problems, then you have met or exceeded your expectations, and nothing further is needed. At my first job, supporting the West Coast with their software, we had a person who’s full time job was to be the communicator between my solutions and their problems. [Thanks Betsy] She always knew what was going on at the company, talked to the higher ups, and let the rest of us in on the secrets.

On the Business side, communication is probably the number 1 priority for their first jobs. Consultants prove their value with status reports and deliverables; project managers have meetings to keep up with what is going on, and team-leads or first-time managers report to their managers on the status of their people. They have learned the art of communication from the bottom up. However, they still may not be able to effectively communicate with many in IT.

The problem could simply be one of attention. IT people tend to be detail oriented. When they get task focused, they see the details and need to handle them. When asked for status, they will talk about what they are working on, which could be the details. Looking at the details of any project can be confusing if you don’t have the intimate details. It’s probably not what a project manager really wants anyway. They most likely want a quick summary of all the tasks, not just the current trouble.

Another problem could be one of personality. Many IT people are introverted. That could mean that talking to others, especially new people, is draining on them emotionally and physically. Even if an introverted person is good at getting his/her point across, it may be tiring to do so. That person probably won’t seek out the opportunity to talk to people who will need excessive explanations. An extroverted person, however, may just expect people to come to him when needed. If that doesn’t happen then tasks can be lost, and a crisis could occur.

Some IT people focus on the infrastructure. They like to talk about the servers, the network, the bandwidth, etc. Some IT people focus on the software. They like to talk about the programs, the operating system, the customizations, etc. If the person on the receiving end of this conversation is not fluent in the IT-speak of the moment, then this will not be a fun discussion. It is so important to be speaking the same language.

A problem that can occur between beginner IT staff and executives is one of priorities. Many IT staffers are reactive. They will fix things as they break, and then move on to the next problem. Executives, especially higher up executives such as the ones at the C-level, want longer term solutions. They want to talk about pro-active solutions. They want to know what the new system will cost, once they see that the old system has problems. It’s difficult for people with such differing priorities to settle down on one topic.

Finally, there’s the idea of independence. Many IT people are such good problem solvers that they want to work alone. They feel that if they are qualified to reach their goals by themselves, then why do they need interference? Some highly experienced IT people may have gotten where they are by being the hero and getting past any dilemma. They may not want to work with other people. It may even be worse if the other people don’t understand what he/she is doing.

We’ve all seen, or been involved in, bad communication issues between people of differing backgrounds. At work, it can be even worse. People working in different functional departments don’t always understand the other people at the company. We all need to work on our communication skills, take a look at the world from someone else’s viewpoint, and be patient.

I’m not trying to imply that this is the whole of reality, and that all IT people, and business types, fit into these categories. I am simply making observations of my world and trying to write something that might help. Knowing how someone else is thinking just may help you get your point across.

So go out there and communicate!

Your Project is Delayed. Now What? 08/28/2009

Posted by tboehm30 in CRM, ERP.
Tags: , , , ,
2 comments

There are plenty of statistics showing how many IT projects are not finished on time, go over the schedule, and are delayed. One recent study said as many as 97% of projects were not finished on time in 2008.

There are plenty of reasons why projects are delayedf, and plenty of articles detailing what to look for, how to try to prevent the problems, and what are the biggest causes. Bad planning, poor estimations, scope creep, lack of cooperation, bad luck, lack of resources, changing resources, all of these can affect the timing of your project.

Computers make things seem simple, but when you get to the details, it may take you longer than you think to finish. An IT project going over its schedule is nothing out of the ordinary.

However, once you are there inside the delay, then what? Anybody working on the tasks within the critical path will obviously be pretty busy. They are the ones who are most likely behind and need to catch up. They are the ones who are probably most worried. They are probably promising only a short delay and working hard so as to not be blamed for a huge failure.

What about people on the project who are in a waiting mode? What are they supposed to do? The risk for these people is loss of momentum. They may see the gap ahead of them, put aside the project and work on other issues. They may forget all that they have learned with regards to the new software, processes, or training. They may find other important tasks that will take priority when the project finally gets back to them.

If it is a short delay, then finding tasks for these people to accomplish won’t be hard. Projects can always use more people checking on quality issues and trying to make things better. Documentation is usually a weak spot that can be strengthened during an unplanned delay. If possible, adding to the testing processes as well as better training for newly added or existing testers is a good time-filling task. Training and documentation for the training is usually one of those last minute issues that could be done by people with a little available time during a delay.

What if the delay is longer? An ERP project will usually involve the migration of an accounting system. They may not want to go-live until a month end. That means a delay of even a few days will result in a full month of downtime.

It could be even worse. If the public company is worried about SOX and auditors and getting their public numbers out the door, this may cause further delay. There are plenty of good reasons not to go-live in the fourth quarter of the year. The fourth quarter may be when all of the auditing happens and executives may not be comfortable making major changes right when they are signing off on the quality of their company.

The project may be further delayed simply because they can’t spare the time. The accountants are busy on their old system, or manually if they don’t have one, closing the books every month. They spend a lot of time every month, every quarter, and every year end balancing the books. They may need to wait for the ‘best’ time for a go-live.

If your project is delayed by months, then you’ll need to make sure you keep people up-to-date. You will need to make sure people get re-trained. You have to keep people involved.

In a previous blog, I wrote about Mini-Pilots. That is a great way to keep people involved. You don’t want them to lose sight of the final goal, and their responsibilities to get there.

Another way I get people to work on the project is ask for more testing. Being technical, I can load data, setup programs, and create data. I then ask the appropriate people to validate my work. They need to see if what I did is what we want to happen after go-live. They may need to test the programs I setup, or look at the data to make sure there are no complications.

For an accounting system, I have plenty of options for processes to validate. I can load inventory, shipments, orders, invoices, etc. and then get accounting to see if the transactions are accurately reflected in the General Ledger. I can load trial balances and hand them over to accounting to make sure they balance with the right accounts.

In manufacturing, I can run MRP and then get people to make sure that the right reports have been generated. I need to make sure that after we go-live they will know how to fulfill their orders. After that, we can check the transactions to the G/L to make sure the costs rolled up correctly.

In a CRM system, I would make spreadsheets with sample data and have people try to use that data as if it came from a customer. I would also schedule meetings where people can pair up, with one person pretending to be the customer calling the other.

The sales people will need good reports. A delay is a great time to have them ask for more details. Unless the report writers are still on the critical path, they can be fixing reports. Usually the reports are one of the last things to be changed. No one really knows what they need until they need it, and that is usually after go-live. Now is the time to get people to really study the new reports and ask for the changes they will need.

The other important thing to do during a long delay is to ensure communication. People need to know that their deadlines have been extended. Some of them may be breathing a big sigh of relief. They need to be reminded when the time gets close again. During a long delay they easily could have forgotten about the project. It will be up to the project management to push people back on track when the time is right.

Even when the project is not at full steam, it’s a global world out there, and Technology makes it happen.

ERP Mini-pilots: How to implement an ERP system 08/07/2009

Posted by tboehm30 in ERP.
Tags: , , , ,
3 comments

One of the keys to success in a new software system implementation is to get everyone familiar with the system in advance of go-live. If someone is learning the system on the first day, then that is too late for them. The users of the system need time in advance to play with the system, to experiment with different methods, and to become familiar with using the software.

Now is the time on my current project when everyone should be doing mini-pilots. They should be working on their own with the new ERP system. The accountants are changing the accounting parameters to see the repercussions of certain actions. They are trying out processes such as invoicing, accounts payable, and accounts receivable. They then check the journal entries to validate the accuracy of the transactions. They are cutting checks and running reports.

The people who are in charge of manufacturing are trying out the MRP system. They are creating work orders, purchase orders, and receiving inventory. They are inventing routings, BOMS, and work centers. They are checking that the cost rollups work correctly. The manufacturing processes must work smoothly on day one because that is the way the company makes money. Without a clean manufacturing process implementation, the project won’t be declared a success.

A big ERP system has hundreds or thousands of parameters that can change the way that the software behaves. Accounting needs to make sure that each activity is tracked in the correct account. Since the system is flexible enough to handle dozens of different types of processes, the accounting codes are determined by a very complicated setup linking products, customers, account types, and account codes. The parameters have to all be right, and now is the time to make sure they are set correctly.

No detail is too small to test. When a sales order is created, turned into a work order, then invoiced, and paid, we will need reports all the way through the process. Each report has to be carefully studied to validate the data. Any time a major parameter is changed, the whole process should be repeated.

Purchase orders, or purchase requests, have an approval process that needs to be setup and tested. Security has to be in place – or at least planned – so that people can’t be making changes that affect the rest of the company. Knowledge has to be shared so that parameters aren’t changed and then changed back without everyone knowing.

Everyone is working hard to learn the new system. There are literally hundreds of parameters and setup features that they are looking at. Can the users receive more product than originally ordered? Can users pay out a different amount than was on the original PO? Are users allowed to run batch processes?

Every screen has to be tested and validated. Any time a screen doesn’t behave as expected, the parameters are checked and changed to fix the problem. That means going back to the beginning again and verifying that the parameter change didn’t alter the original behavior of other transactions.

We also learn more about the system every time something doesn’t work as expected. We dig into the details to figure out the answer. If we figure it out ourselves, it is a success that won’t be easily forgotten. If we need help from the vendor, then they usually give a great summary of related issues.

This time period is a very unstructured time. Everyone is working on their own, doing their own thing. We won’t know how much real work they have put in, until the next meeting where we go over the system. I haven’t given them a schedule like I have for the Conference Room Pilots. Since I am working with responsible, hard-working people, I know that they will figure it out.

The time to do Mini-Pilots needs to be long enough (more than a week) to allow people to get a good feeling for the software. It also needs to be short enough (less than 6 weeks) so that people feel the pressure to work hard. If the time is too long, then people will tend to procrastinate thinking they have plenty of time.

As the consultant driving the implementation, I have been trying to meet with people to get their impressions. I have worked with people on different functional areas to help them understand the software. I have been inserting myself into their daily routine so that they won’t forget about the project.

I think it is working, because people are starting to get nervous. They are working even harder knowing that the go-live is getting closer.

This is great because we all know that it’s a global world out there and Technology makes it happen.

Running a Conference Room Pilot 07/10/2009

Posted by tboehm30 in CRM, ERP.
Tags: , , , , ,
1 comment so far

Whenever you are installing a large software system, whether it is CRM or ERP, or any other system, if you are part of a plan to integrate the system, you will need a pilot. The conference room pilot is a time to practice what you will do after go-live. It should be a safe environment to explore options and ask questions. It should be a time to document user processes. The conference room pilot needs to give everyone the confidence that the project will succeed.

My current project includes 2 conference room pilots plus a dry run for each business unit going live with the system. Each pilot is scheduled for a full week, 8 hours per day. The first pilot could have been better. Everyone realized that they were behind in their plans and were not ready. The second pilot went much better. People realized that they needed to work harder, study more and practice every day. They had been motivated by the first pilot to figure out what they needed for success.

The first thing to consider in running a conference room pilot is where to conduct it. As the name implies, you will need a large room. People from different areas will be coming in and out of the pilot, plus a core group who will always be there. You should expect one or more consultants from the software vendor, your implementer, or other companies included in the project. The room needs to be able to accommodate the full compliment of people plus room for storing their things, putting snacks on a table, etc.

Of course you will need the right technology in the room. I suggest having at least 4 computers wired into your network available for general use. Make sure there are enough cables and outlets or wireless for others to use a laptop. Have a projector so everyone can watch what is going on.

If you expect some people to be in the room all day, it might be nice to provide drinks or snacks to help them make it through. Mints or gum can help them stay away during that occasional drowsy period (although most of the day should be very exciting).

I created a general schedule for the first pilot. This included the discipline area and the general tasks to be completed. The schedule was set at four hour intervals or two main sections of the day. This allowed the users to show us what they knew, but allowed plenty of time to ask questions, experiment, and figure out how to run the system.

The schedule for the second pilot contained much more detail. I scheduled events to each hour, expecting people to know what they were doing and how to do it. Each person who needed to run the computer connected to the projector knew exactly when to be in the room and how they needed to prepare.

I also created data in advance so that each step would have the necessary background already in the database. For example, to manufacture a product, they need inventory to consume. I created the inventory in advance. To receive something into the system, they needed to already have a purchase order approved. I created and approved numerous types of POs into the system.

Everybody brought their document business procedures to the room. When it was their turn to ‘drive’ they followed the documented procedures creating each item on the list. We had the vendor’s consultants as well, and there was plenty of time for questions. Predictably, we had some people who needed more help than expected. Those sessions would run over, and delay the entire schedule.

To better accommodate those people, we had a second room setup. That room was just as large as the main room, with computers and a projector as well. We had groups of people meet in that room to go over issues and solve problems. Because we had more than one consultant from the vendor, we could easily split up into functional groups and get the full value of their time.

The write-up from the second pilot included the steps we still need to take for success. We have several groups who will meet more often to practice with the software. Some of them may do ‘mini-pilots’ in the same room already setup. We know that security is still an issue, but hope to practice with that during our dry-run.

Some companies will try to run parallel systems. With the changing technologies, that is becoming less valuable. It is very difficult to compare diverse systems, so people end up spending too much time chasing down issues that are not problems.

With a little preparation the conference room pilots can be very valuable. If people know what to expect and how to prepare, they will be able to show that they are ready for go-live. Seeing their people use the system in a realistic setting will allow the core team to have confidence in their people. This is the environment that will keep the company on the road to a successful system implementation.

We all know that it’s a global world out there and Technology makes it happen.

ERP Newsletter Articles 06/08/2009

Posted by tboehm30 in ERP.
Tags: , , ,
1 comment so far

I have now published 2 newsletter articles with Imninc.com. The first one was a good summary of my current project on topics I had already put in the blog. This second one came out pretty good, so I am putting it here as well:
A View from the Trenches – Part II
In part one of A View from the Trenches, I introduced myself as a technology consultant working with a medical manufacturer that needs an ERP system (Enterprise Resource Planning). I was brought in to run the software selection project for the system, and I am the full-time driver for a large committee consisting of several representatives from several business units.

The last article ended with full buy-in from executive management as I walked through the challenges and political implications of working with a large committee. Now, we’ve reached a new phase: preparing for go-live.

Large software implementations such as ERP systems take a lot of coordination and effort to keep on track. Once the initial excitement has tapered off, people have trouble staying focused. They may feel they have plenty of time before go-live, and they aren’t too worried about project tasks, because they can make up the time later.

I’m living that reality right now. We are planning the go-live for the first of September, so that gives us all summer to be ready. We just finished four weeks of meetings to go over software settings and business processes. We had very good participation, and the results were promising. People saw the new processes, got some experience with the software and received their assignments for the next few weeks. It seems fairly cut and dry, but in most projects, managing people and behaviors is the biggest challenge of all.

I understand how my client’s employees must feel. They already have the full time job of keeping the factory going by making products and bringing in revenue, all while dealing with training, implementation and adaptation of a new system. But their business performance is important to me as well. As an outside consultant, I’m getting paid to help drive the implementation without disrupting ongoing operations. I can’t overwhelm them with project tasks, but it’s my responsibility to keep them on target with the project.

Companies bring in consultants like me to augment their staff in running large projects. This particular client runs very lean, and doesn’t have extra staff that can concentrate on special projects or drive system implementations. Motivating busy staff to stay on track with a project while balancing their daily responsibilities takes a careful balance of meetings and assignments. We meet once a week to discuss progress, but that is not enough. I try to talk to everyone in the PMO (Project Management Office) as much as possible, assigning deadlines and explaining how one person’s task relies on another person finishing their work. No one wants to be the bottleneck, so these discussions keep everyone focused on the goal.

Giving people specific tasks with a real timeline allows the project to continue at a steady pace. We avoid disrupting normal operations, and allow leeway for emergencies that tend to pop up, but the project must go on. We push forward because this new ERP system will allow the company to close the books much faster than the present system. Soon, they will have better insight into their operations, inventory and cash flow.

It’s common knowledge that the new system is a key step toward growth for the company, with numerous benefits. However, it is difficult for anyone to stay focused for numerous consecutive months. The exuberance from the beginning of the project has been drained by meetings, details and day-to-day responsibilities. We are now at a point where motivation is critical to maintain momentum.

So, what have we done to prepare for go-live? One of my first steps was to figure out individual jobs that would lead to the larger tasks on the project plan. I then described the jobs to the people who needed to pass them out to their team. We had to be ready for the first conference room pilot in a couple of weeks. Our plan was to get all the right people in the same room and simulate a manufacturing cycle with all related accounting activities.

I found that an informal description of tasks didn’t have the intended result. The information was not passed down, and people were not doing their work for the project. No one made it a priority to learn the system, get processes ready or take responsibility. There was a false perception that there was still plenty of time to get all of that done, just not today.

Around this time, I had a meeting with the right person – a staff member who could see the big picture and how it impacted the company. When I described what needed to be done, he started to get nervous. He could see how much information was needed and began to ask questions. I immediately asked him to help me get people more involved.

We gathered the troops in a large meeting where we went over the system and explained the project status. I formally asked them to send me information about their goals for the project by offering a sample list of scenarios and asking them to look at the list and follow-up by determining their area of responsibility. Creating a starting point for team members prevented them from feeling overwhelmed, while opening the door for them to add action items to the list when needed.

During the meeting I showed the group a few pictures of “broken” signs. My favorite is a large sign that says “Caution, this sign has sharp edges”. My point is that the group in the room is responsible for making sure we don’t produce a poor end product. I asked the team to speak up or yell if they think that we are about to produce something as bad as the sign that said: “This sign not in use.”

When the broken signs tactic didn’t produce immediate results, I followed up with emails asking them to reply by the end of the next day. I then followed up with phone calls to get the information I needed.

Getting the right person involved, who was nervous enough to get others to step up, was a great step forward. Now my primary task is to keep interest and participation high.

The current project plan allows us a week to complete this pilot while fully documenting the process. We’ll have another week afterward to figure out what went wrong and what to do to fix the problems that occur. Then, we’ll do a second pilot. I’ll need the full participation of team members with that one, too.

There are plenty of abysmal statistics on failure rates of software projects, but with the right management and participation, any project can succeed. As we enter the pilot phase of our project, I am optimistic that we will continue to keep the right team in place to stay concerned and alert about the project status, ensuring a successful implementation.