jump to navigation

Gathering ERP Requirements 01/01/2010

Posted by TBoehm30 in ERP, Project Management, Software.
Tags: , , , , ,
6 comments

One of the most important steps of any software project, especially the choice of an ERP system, is to gather requirements. You need to know what is needed, what is wanted, and what you can do without. You need to have an idea of what to look for in a complicated system. You also need to have an idea of how you are going to be ready for the new system and what abilities you have or will need to implement the new system.

When you are looking at acquiring a new ERP system, you need to know what you want. The definition of ERP is very loose, and could include modules that you don’t need, or not include modules that you will eventually want. Before you look at new ERP systems, you need to take an internal look at your own company and document your requirements. Do you need manufacturing? How about accounting? CRM? Is a data warehouse important?

Most of the time, employees are too busy and too close the problem to accurately document what is needed. Consultants are great at gathering requirements because they have general knowledge of systems, and know how to talk to the people in your company who can best describe your desires. Where an employee can’t see the forest for the trees, a consultant usually keeps the big picture in focus while still understanding the details.

Gathering requirements has numerous stages. First the person or team responsible will identify the knowledge experts to interview everyone who might be important to the project. Some consultants will have a checklist or a set of questions already created to aid in the process.

Once the discussions have occurred, the next stage is analysis. The requirements need to be evaluated and prioritized. Priorities are important for people to come back to during the life of the project. To ensure the full use of these priorities, the requirements must be properly documented. They must contain very specific information so no one would be confused.

The documented requirements should be as specific as possible. Any vague descriptions or goals could lead to problems down the line. Some people may know exactly what they want, but if it is not described exactly they risk not getting what they want. They could also get a system that matches the requirements but doesn’t fulfill the needs of the company. Being as technically precise as possible is a key characteristic of good requirements.

Once the requirements are created, they should be validated. A team of employees or management should sign off on them. Having more people review the documents will lead to fewer disagreements down the line.

Finally, the requirements need to be managed. Once everyone knows what they want, it won’t work to put the documents on a shelf. They should be a living document that changes as new knowledge is gathered. Keeping the documentation current will allow parties to stay on the same path.

Requirements should include everything that you want out of a new system. Functional requirements are obvious; your system should provide all of the new services you need. Your documentation should also include non-functional requirements such as security plans, reliability expectations, availability, etc. You may need new space to put the equipment, you may need new training, you may even need to slow down existing schedules to get the new system going.

Some needs will be out of scope. It is important to not spend too much time on issues that won’t affect the project. If you are buying new software, some people may want to argue about the hardware that will be needed. You could wait until you get recommendations from the final chosen vendor before you choose the hardware. Debating the details before you are ready is just a waste of time.

There are many ways to get a set of requirements done. You can use prototyping, storyboards, modeling, state transition diagrams, use case analysis, or just plain text to describe what you want. No matter which way you choose, there are plenty of examples on the internet to give you a template to begin. Another reason that consultants are great is that they will have templates already created to drive the requirements project.

Most projects begin because somebody has an idea of what they want. Unless everybody knows what is needed, the project won’t succeed. Gathering the requirements is the step that will guarantee that everyone is working on the same path to success. Don’t be negative in the requirements, say what you want and stay true to the needs of the company.

I know that you can do a great job with those requirements. If you need help, then get it; because it’s a global world out there and Technology makes it happen.

Advertisements

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!

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.