jump to navigation

How close is your software vendor? 10/12/2011

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


The other day I had a software problem.  My client had come to me with an issue and I had to come up with a solution.  I have been working with them for a while so I know their software pretty well.  I can usually figure out their problems and either solve them or come up with a workaround.  At the very least I can use their testing environment to document all the steps to recreate the problem as well as the steps taken to try to solve it.

My client has a valid contract with the software vendor and has full access to their help desk.  I am sure you have dealt with many ‘help’ desks and are completely familiar with what that means.  Some of them are very good and some of them are worse than a hot day in the desert.  I have to admit that this one is actually pretty good.

The trick is in the communication.  The people who I work with can’t always communicate their problems in such a way that the help desk can solve them.  They also have trouble understanding the responses.  Sometimes the tech-speak is just too complicated.  That’s where I come in.  I can help translate for both sides to get the problem solved.

Today, I found what I thought was a bug in the software.  The company that created this software is very sensitive about criticism of their programs.  I didn’t want to go to the help desk with this one until I had verified functionality with one of their senior consultants.  Since I am on good terms with several of them, my options were open.

The project manager for our implementation likes for me to go through him before talking to the consultants.  I shot him an email with my problem.  Within a few hours he had confirmed my problem, sent it off to tech support, and came back with a solution.  It wasn’t really a bug, but a setup problem.

I have dealt with many software companies throughout my career.  I have talked to people who were really good at their job, but the company was terrible; and I have talked to people who couldn’t help a cat out of a bag, even when their company was great.  A response within a few hours with a solution, going around the help desk, is above average support.  I would recommend that any day of the week.

When you are looking for software it is important to determine what kind of relationships they develop with their clients.  Sure, you will get references and talk to them about the pros and cons about the software; but you also need to find out about their responsiveness.  You need to find out about their personnel.  Do they stay in touch with their clients?  Do they come back to find out if there are any lingering issues?

Before you make a decision on your software, find out who your main contact will be.  Try to meet with him or her at a time and place where you have plenty of time for questions.  This person needs to be someone with whom you can trust and build a relationship.  They need to listen; you need to feel like they are listening to you and not thinking about what they will say next.  They need to be flexible.  Throw them a hypothetical curve ball; how do they react?

If this person doesn’t meet your criteria, don’t abandon the software vendor entirely, just ask for someone else.  Most companies would be happy to switch personnel if it means a chance for a sale.  Make sure you still have time to repeat the process with someone new.

My criteria is for someone who understands that it’s a global world out there and Technology makes it happen.

Conference Room Pilot Techniques – The First One 03/28/2011

Posted by TBoehm30 in Conference Room Pilot.
Tags: , , , , , , ,

 A new ERP system (or any new software) can be a huge project.  It takes coordinated planning to get it implemented on time and on budget.  One of the tools used to keep people on task is the Conference Room Pilot (CRP).

The CRP is where you can figure out what to do on your new software system, and practice what you think you know how to do.  You should have the chance to demonstrate to management, the software vendor, and your consultants that you will be ready for go-live.  If you are not prepared for the go-live, this is where it will show up.  The decision to delay should be made after a bad pilot, and not hours before a go-live deadline.

When should you conduct the first CRP?  When you sign the contract for a new software system, the first plans to make are for training and implementation.  The length of the project will determine when you should schedule the pilots and dry run(s).  After approximately 1/3 of the project time is done, you should be able to have a good CRP.  If the project is going to last 6 months, then 2 months of practice should be sufficient to get together as a group and officially go through the software to practice your business processes.

There are several ways you can go through the software.  You can start at the first menu and work your way to the bottom.  You can start at the beginning of the documentation and follow it like a guide to the end.  You can create test scripts and test each process that you will need.  You bring in each employee who will use the system and have them show you what they know.  People could come in alphabetically, or in the logical order of your choice.

The right way to do this, however, is to concentrate on your business processes.  It is not enough to know how to use the receipt screen to receive boxes off the dock.  Your people need to know what to do when there is a box on the dock.  They need to know that if the box is there, then they will need to go to the receipt screen.  They should know how to print the receiving documents and who will take them to get the products put away or quality tested.  The quality people need to know who will be giving them new products and then how to mark them as tested in the system.

The business processes should be documented and brought into the CRP for validation and correction.  If you have the software vendor or outside consultants with you at the pilot, they can help you to refine the processes and determine best practices.  You need to schedule the pilot in a logical order such as starting with the Sales Orders, proceeding through the manufacturing and shipping processes to the invoice and A/R process.  This will allow a smooth handoff between groups.

Understanding the business processes and how to use the new system to follow the processes is the single most important aspect of the CRP.  The handoff of processes should be practiced until it is second nature.  People should be living and breathing their new processes as much as possible until the switch is flipped at go-live when the new software is turned on and used to run the business.

There are other concerns for the first pilot.  You need to have gotten legacy data into the system.  If the data is loaded through an automated system, then you should have plenty of data to play with.  If it is being manually loaded, then you should be well on the way to having it all done.  You can use the first CRP as a chance to validate the way the data is entered into the system.  You will find problems such as decisions made to manage products, the setup of BOMs, or the default address settings for customers.  You still have plenty of time to get those problems fixed and re-tested.

Beyond static data such as customer, suppliers, products, BOMs, Routings, Installed Equipment, etc.; you need to have practiced getting transactional data into the system.  If the software is replacing an existing system or process, then you will have to add in Sales Orders, Work Orders, Purchase Orders, A/R, A/P, Customer Complaint Cases, etc. The CRP will be a good time to use the data to validate that it is being loaded or entered correctly.

Reports is something to think about, but at a lower priority.  You will need some reports for the CRP, but you won’t have time to finalize many of them.  The CRP will be a good time to see if out-of-the-box reports will be good enough for your processes.  If not, you can spend a short amount of time noting changes, and get that into the queue to have done before go-live.

Security is another item to put on the list, but not as a priority for the CRP.  You will need separation of duties, or division of data between sites, or people.  There are going to be plenty of functionality that you don’t want everyone to have.  Setting that up too early could make a CRP more difficult.  If a user doesn’t have the authority to get into screens required for their job would slow down a CRP.  You can wait as long as the final Dry Run before setting up true security.

You may think that the system is completely setup after 2 months of practice, but in my experience, you always find little things that can be improved.  A parameter here, a setup item there, a dropdown that can be tweaked are things that might be suggested during the CRP.  These should be carefully tracked so that they can be duplicated on a Production system.  It is not terribly important to get all of that correct this early.

If planned from the beginning, your CRP can be a successful way to keep the project on schedule.  It shows everyone that people are practicing with the new system and working hard toward go-live.  It will give people the confidence to keep on working hard to be ready for that terrific day when the new software is finally turned on to run the business.

On the other hand, a poor CRP could also motivate people to work harder.  If the project team gets good constructive criticism, they might decide to turn things around.  At the first CRP, you still should have plenty of time to fix the project and get it turned around. 

Tell me your stories of the Conference Room Pilot – good or bad.  I know you’ve got them because it’s a global world out there and Technology makes it happen.

Test Before Installing an Upgrade 10/29/2010

Posted by TBoehm30 in Software.
Tags: , , , , , , , , , ,
add a comment

A new risk to your software is coming; it is time for an upgrade.  Remember when your system was new?  Remember that huge project to implement the software?  Now, it seems, you don’t know how you survived without it.  Don’t take unnecessary risks; make sure you are prepared for this upgrade.

An upgrade may just be a small change, it could be a large change, it could be a few patches, it could be a brand new user interface, and it could contain brand new modules.  No matter the size, you want to make sure that this upgrade doesn’t break any critical processes before you install it.  Even if you get experts to put it in, you will want to do some testing first.

There are several ways of getting an upgrade installed.  You can get the software company to do it for you.  This can be included in your support contract, or you might pay extra for it.  You could hire a consultant who is an expert on the software you are using.  If you are going this route it is best when you have a working relationship with the consultants so that they understand your business as well as the specific software.  You can also do it yourself.  Many software companies provide instructions for how to put in the new code.

The first step, however, is always going to be testing.  A good software company will test the upgrades themselves.  The reason you pay money for the software support is so that you can trust the software will do what it is supposed to.  If the software doesn’t do what you want, you can call the company for help.  A good consultant will schedule in plenty of testing before an upgrade.  They should know what the upgrade is meant to improve, and with a good understanding of your company, should know what to test.  Of course, if you do this yourself, then testing should be second nature.

There are several areas to test before upgrading.  Any customization to the software should be at the top of the list.  Since you changed the default behavior of the program, you hope that the underlying logic didn’t change.  If it did, you will need to either remove your customization, or re-create the custom code on the new version of the software.

The next areas to test require a little bit of study.  Usually the software company will publish documentation on the changes.  You should review those changes and mark any functionality that is critical.  Sometimes the documentation can be technical and confusing; if that is the case, simply write down the module, area, functionality, or process that needs to be tested. 

Last on the list of testing is any other area you think should be tested before an upgrade.  I have seen people just do a full validation before any upgrade. 

During the implementation phase for this software, you documented your business processes.  Hopefully, you had a documented test script.  Save those!  If you have good test scripts, they can be used again for this process.  If you don’t have test scripts, then make them now and you can use them for each upgrade.  Spend some time on those scripts, they are valuable.  If you have a good set of test scripts, then you understand your system; you have the ability to validate your system and your data.

Make a list of all the functionalities that are important to you.  Start out with broad categories such as A/P, A/R, Manufacturing, or CRM.  Then narrow the focus to specifics such as returning merchandise, or receiving a complaint from a customer.  If you document the steps you take for each of these specifics, and make screen shots of the results, you are on your way to a great set of test scripts.

Before letting anyone upgrade your software system, make sure you back up all of your data.  Make sure you can restore yourself to the previous version in case catastrophe strikes. 

If you have properly tested the new software, then you shouldn’t run into any surprises.  Remember, it’s a global world out there and Technology makes it happen.

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

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

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!

Technology Projects – Talk to Users 03/27/2009

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

In the days when I did projects creating forms for a CRM system, I talked to many different people. Sometimes, though, I talked to the wrong people.

Usually the request for some new customization came from the steering committee. The steering committee got their requests from management. Management got their requests from their team leads who in turn got their ideas from the team.

Most requests were straightforward and well thought out. They required a new checkbox or dropdown on an existing form; maybe they also needed some new fields and reports to handle the new data. The biggest projects were longer and required teams of people. They had project managers, testers, designers, etc. The projects in the middle, however, were the most interesting.

The middle sized projects were usually very focused, but not technically spelled out. It was up to me to determine if we needed a new form, or could be added on to an existing form. I had to design the layout, the format, and the process.

One particular project stands out.
I had to design a parts order and tracking form. It needed to be simple with only 15 – 20 controls, most of them pre-defined as dropdowns, or checkboxes. I talked to many of the users to format the screen so that it followed their process. The first person using the form would use the top row of controls. The next person using the form would use the next row of controls, and so on. I then took the complete form to the manager of the group, who completely rearranged the format.

The manager needed the form organized so that he could look for specific issues easily. That meant controls from each row be put at the top getting his attention quickly. I worked hard to make him happy by creating the form for his use. At the end he was extremely satisfied with the result. As an outside consultant, I thought I had done a great job by keeping the managers happy.

Then the form went into production. Ooops. The users hated it. It was no longer intuitive, and they had to concentrate very hard to use the new form. Mistakes were easy to make on the form, and that confused the process. To make matters worse, the manager never actually used the form; he looked at reports to find the problems.

I learned my lesson: Talk to the Users of technology. When working on a project, you need to understand who the end users will be. Who will be interacting with the product you are working on? It is those people you need to get the most input from. If management decides to make changes, then I need to talk them out of it. I need to convince them that there is a better way. Next time, if management needs a separate project just for them, then that’s the way to go.

Thanks to SellGoSell for the idea for this blog. He writes a great story in his sideways lesson.

Remember that it’s the final user of the product that will ultimately determine the success of your project. They are the ones who understand the part about Technology making it happen.