How to Prepare and Conduct an ERP Pre-Sales Demo

group-studyFor the past several weeks I have been tasked to help our sales team conduct pre-sales activities for prospective ERP clients. Initially, I did not know what to do and what to expect but after looking at the task in its entirety it started to look doable. All I need is a plan, a good plan that is. 

This is an unfamiliar territory for me since I have never been in the front line before. Typically, when I meet up with the client, the Project is on the Implementation stage already. I meet them as a project lead/manager or as a consultant, not as part of a well-dressed sales team.

During the course of the whole assignment, I found out that I could capitalize on the skills I acquired in implementing ERP Projects. In fact, I am a bit guilty of enjoying the task so much so that I decided to write a “How-to” blog to share my experience.

First thing I did was to divide my task in three major activities.

  • Initial Data Gathering
  • Demo Preparation
  • Actual Demo

Whatever activities the sales team does before or after these are not included in this blog. Just to be clear.

By having a plan, I completed the assignment in no time. Here are some tips on how to go about this (special) task.

  1. Identify the unique. During the initial data gathering stage, give special attention to the unique requirements of the client. Most businesses follow a similar process flow specially in the operations aspect, but what you need to know and identify are the processes that are unique to their business. It could be the way they approve a sales order or the way they deliver their goods or how they add cost to their inventory. These are the things you need to prepare for and tackle during the course of your presentation.
  2. Stick to the standard. When you address operational concerns, make sure you answer them based on the standard ERP package that you are carrying. This will help identify whether the standard solution would be able to suffice their requirements. If you quickly jump to a customisation, then you are merely stressing that your ERP solution does not fit their business and it will not be good for you as a potential ERP partner.
  3. Don’t beat around the bush. Sincerity and honesty are the two most important virtues you need to send across the table. Do not try to intimidate or confuse the client with a very long answer that has no clear direction whether your answer is a yes or a no. Chances are, they will recognise what you are doing and that might have a negative effect. If your answer is no always have a work-around if possible.
  4. Ask questions strategically. This can be achieved by always starting the series of questions that has something to do with Sales process. Nothing gets the clients’ attention more effectively than asking them how they process their sales. In retrospect, companies that are having problems with their sales process are the ones looking for a good ERP solution rather than those having difficulties with their payable process. Assets are always more fun to discuss than liabilities.
  5. Prepare Demo Scenarios. After the initial data gathering, what you need to do is to go back to the office and start a list of all the scenarios and group them per business unit. These scenarios could also be classified under standard, work-around or customisation. Bottom line is, you need to address these in your demo. It would also help to start with the basic scenario down to the most complicated one.
  6. Model each scenario in your ERP Package. In conjunction with no. 5, make sure you model all scenarios to your ERP package. A complete model is a manifestation of your competitiveness as an ERP solution partner and provider.
  7. Know your audience. This is very important specially during the actual demo. Everything is dictated by who you are going to interact with. Most of the time, it’s going to be the upper management but it’s always good to know who these people are and their functions so you won’t get any surprise questions during the actual product demo.
  8. The Power of PowerPoint. For good measure, prepare a power point slide that will illustrate an overview of what they will see and hear from you. Showing a top-level process flow will never get you wrong specially for upper management level type of presentation. Make them visualise your solution.
  9. A little animation won’t hurt. Let’s face it, people never really outgrow animation. There are so many things you can do with power point, animation is one of them. Seeing their stocks being allocated with a flying motion or a sales document moving across the screen from different sources and consolidate into a common location will always give them an impression that your solution will make a particular task easy and automatically for them. Not to mention a show which they will remember long after you leave their office.
  10. Plant a question on their mind.  This is a very tricky technique but with proper practice and a little bit of planning, it can be achieved and pays big dividends. It means that you plant a question on their heads without making them realise it. It will lead them to ask you a question that you already anticipated. Your answer will be direct and swift and it will show your confidence level.
  11. Presence of mind by focusing on the task. It is very easy to lose focus during the product demo specially for someone who is an ERP consultant. The task is pre-sales, not training and certainly not Business Analysis. Do not say things that are not necessary. Always remember that you are trying to get the project, not train your audience.
  12. End with a simple yet comprehensive visual flow. As much as possible, make sure your last slide or the last slide before your “Q & A” slide, shows the complete solution that you are proposing. Give them something to remember, an imprint that your proposal can cover everything from start to finish. The key is to make them recall what you have proposed that day because that is important when they start their evaluation process.

These are some tips which I think is very useful in preparing for a Pre-Sales Demo. It worked for me and it might work for you too.

If any of you are interested, so far out of 4 pre-sales demo that I conducted, the results are: 2 clients confirmed, 1 verbally said yes and 1 still in evaluation process between us (Microsoft Dynamics NAV), SAP and Oracle. Talk about big guns. :o)  

 

Posted in Uncategorized | Tagged , , , , , , , , , , , , , , , , | Leave a comment

How to perform a good Business Analysis

Image

As I have mentioned on my previous blog on How to conduct an effective Requirements Gathering, the input document in that activity is the Requirements List from your Sales Team. Now, the output document is still the Requirements List but this time it’s an even more detailed version.

The project team has just come back to office after a grueling week or so of onsite Requirements Gathering. The good news is you got what you want. The bad news is, it’s not time to relax. Now that the dust are all settled its time for the next phase of the project.

Enter Business Analysis.

I have also mentioned from my blog How to conduct an effective Requirements Gathering that I will discuss what is Requirements Analysis and Business Analysis.

Requirements Analysis is an activity that involves both the client and the project team, it is an activity where the project team gathers and records information supplied by the client. While Business Analysis in activity within the project team only, this is where you go through with all the information you have gathered from the previous activity and come up with a solution to all the requirements. Bottlenecks within the business flow are addressed here. This is where you try to improve the business process of the client.

Personally, this is the most challenging part of the project. This is where the whole team rolls up their sleeves, put on their thinking caps and work. This is practically when the backbone of the ERP design that will be rolled-out in the coming months will be defined. This is the time when the project team will lay the foundation of the solution that will be implemented.

Here are some tips on how to go about this very important yet tedious task.

  1. Classify. It is always good to start by splitting the requirements into two general classifications, Standard and Customization. For the sake of everybody, I will briefly explain these two. Standard are requirements that you could deliver without touching a single line of code. While the Customization, as its name suggests are requirements that needs to be developed.
  2. Sub-Divide. After classifying them into two, look closely at the Customization List and further divide it into two again, this time, In-Scope and Out-of-Scope. Since most of the time, out-of-scope requirements are chargeable or up for negotiations. Alert your PMO on the Out-of-Scope list and let him take care of that with the client. I could discuss this extra activity on my future blog.
  3. Use previous Solutions. It is a known fact that there are companies out there with similar workflow thus similar requirements. To save some precious time, it is not a bad idea to implement something that has already been tried and tested with other projects. Use your experience to your advantage.
  4. Involve the Technical Team. While the functional team can handle all functional aspects, it is important to involve the technical team as well specially in a complicated solution that requires extensive coding. Always remember that two heads are always better than one.
  5. Communicate with the Client. It is normal to find yourselves facing a blank wall after a more detailed study of the requirements. There are times when you realize that you failed to ask an important question during the Requirements Analysis phase or there is information that simply needs a confirmation from the stakeholder. Do not hesitate to call the client to ask or confirm. After all that is what those contact details you gathered from them during the Project Kick-off Meeting is for.
  6. The Simpler the Better. During this phase, since the whole team has put on their thinking caps, it is common to over design something. Avoid this! You do not want to build a White Elephant, if you find yourselves designing a very complicated solution, think again. Look at it at a different angle. If you need to involve another colleague to look at it, please do so.
  7. Ask for Opinion. Number 6 kind of preempted this. It is perfectly all right to seek help from other teams in terms of opinion. You will be surprised that sometimes you are able to solve a problem in your head just by discussing it with another person or other team. If the other person has an even better solution then consider it as a bonus. It will not make you a lesser capable Project Manager by asking opinion from others.
  8. Document everything. Make sure you document everything by using your Project management tools. This activity might take you several weeks to finish depending on the scope, so documentation is very crucial. There are several output documents in this activity, which I will discuss in my future blog.

Again you could add some other strategies that you know would work for you. At the end of the day what is important is that the Project team has addressed all requirements and has a workable solution before you meet with the client again. Be wise, be systematic and most of all be patient.

Posted in Project Management | Tagged , , , , , , , , , , , , , , , , | Leave a comment

ERP Project Management: How to effectively conduct a Requirements Analysis.

It is sometimes referred to as Requirements Gathering and most of the time confused with Business Analysis. I will dwell on the difference between these two in my future blog but for now let us focus on Requirements Analysis.

After the Sales team has handed over the project to the project team and after the Project Kick-off meeting there is nothing else to do but to go and start the project proper. It’s time for Requirements Gathering.

The good news is the project team doesn’t sit in front of the stakeholders empty handed. More often than not, the sales team would hand over the requirements list they had prepared during the commercial phase to the project team. That list is the starting point of this activity.

Again more often than not, the list is an overview of the requirements and it is the responsibility of the project team to dig deeper into the pie.

Here are a few tips on how to effectively conduct an effective Requirements Gathering / Analysis:

1. Plan and Prepare. As I have mentioned in my previous blog, this should always be on the very top of each of your activity. Plan by making sure that the schedule fits well to all stakeholders calendar. Typically this activity will last for a week or more depending on the scope of the project. It is important to send them the schedule in advance. Prepare by going through the requirements beforehand, by doing so you will have an idea on what questions to ask and what needs to be discussed more thoroughly.

2. Divide and Conquer. Group your stakeholders in such a way that all the participants’ role is inter-related to each other. The most common grouping of course would be by their respective departments e.g. Purchasing, Sales, Warehouse, Manufacturing, and Finance etc. This way, you will be more focused on one module of your ERP and you will accomplish your task a lot faster.

3. Explain your Methodology. Explaining to them the methodologies that you are going to use at the start of the activity will also help them prepare themselves. There are several tools that you can use for this activity; the most common are Questionnaire and Interview. Aside from these two techniques you can always collaborate it with an impromptu system diagram or system flow to help them visualize what you understand from the information you have just gathered from them.

4. Help them help you. Aside from discussing with them the methodologies that you will use, inform them in advance what you need them to prepare like sample reports, trade documents and even mockup screen shot of what they expect from the system. This will help you and your team to analyze their requirement more effectively.

5. Avoid unnecessary diversion. It’s pretty normal for users and even the project team to lose focus on the topic at hand especially in ERP where everything is intertwined. You’ll often see yourself hovering over other subjects such as Invoicing or Deliveries while discussing about Sales. Try not to divert to that area if you plan to have a separate session with that concerned department. But make sure you link those gaps when you meet with the other teams.

6. Haste makes Waste. During the course of this exercise, it is very common to dwell on similar scenarios like Invoicing for Local customers, Invoicing for Foreign customers and Invoicing for Inter-Company.  Sometimes, you may think that since these are similar there is no need to further discuss on the other two after discussing the first scenario. Do not forget, if there is even a slightest difference between scenarios, all deserves a magnified look. You’ll never know when and where will a system design-changing situation lurks and it could present a problem to you in the future. Haste is your enemy.

7. Review and Seek acknowledgement. It is always a good habit to repeat to the stakeholder the information that you have just gathered from a scenario before moving on to the next one. You may do this by reading out loud what you have just written down or if you are using system diagrams, go through the final version one last time. You’ll be surprised to know that more than 50% of the time, there is a forgotten or misinterpreted information somewhere that needs rectification during this final review. It is important that they acknowledge the information you have just collected.

8. Let them talk while you listen. There are times when you find yourself egging to propose something or telling them what they should do instead of their current practice. Bite your tongue. Remember this is a requirements gathering phase. There is a time for your proposal and for your knowledge in ERP design to be heard. This is not YET the time. You do not want to promise something to them this early in the game just to take it back later on; it could backfire on you on the next stages of the project. So for now, hold on to your horses but make a self-note for your review.

There you go. Following these simple tips could lead to a successful Requirements Gathering/Analysis. Just like on my previous blogs these aren’t the only things that will help you achieve your goal. There are still so many factors out there but what I have just listed above will make you start on the right foot.

Posted in Project Management | Tagged , , , , , , , , , , , , , , , , | 1 Comment

ERP Project Management: How to conduct a Project Kick-off Meeting

The Project Kick-of meeting is probably one of the most important meetings the project team will have to conduct during the course of the whole project, if not the most important. It is the meeting when you give the client the best impression you could afford. The most appropriate time to give them an overview of how the project will be ran. The moment when you let the customer know that you and your team is up for the challenge. In other words this is the moment when you lay your cards on the table.

In my years of working for an ERP solution partner, believe me sometimes this could dictate the success rate of the project.

Here are a few tips on how to make it a successful and meaningful Project Kick-off Meeting.

  1. Plan and Prepare. Yes, this should always be on the very top of your list every time you do something, in this case Kick-off meeting, plan. This is a no-brainer if I may say.
  2. Introduce your team. The customer will have to know who are the people they will be working with. From the Project Manager to the Project Lead to the Consultants (Functional and Technical) and the PMO Officer (Project Management Office). It is always a good idea to bring the whole team.
  3. Know their team. Since you have already introduced your team, then it is only fair for you to know whom are you going to deal with. The Project Manager for their side, the members of the steering committee and all the key users. Be sure to get their names, contact numbers, email addresses and their role in the company. Do not leave without this important information.
  4. Discuss Project Schedule. This is the backbone of the whole exercise. Discuss what happens after the Kick-off meeting and what are the next activity after that and so on and so forth. Now, I have witnessed some Project Managers who doesn’t want to discuss the schedule, BIG mistake! Without the Project Schedule the whole exercise is a failure. It is the right of the customer to at least have an idea on how long the implementation will so they could plan their schedule. Remember this is an essential part of this activity.
  5. Show Project Milestones. While discussing the Project Schedule, highlight the Project Milestones. This will make them visualize the project in significant phases and will give them a good idea on the status of the project during the course of the implementation.  If in case you need to mention your Billing Milestones please do so.
  6. Explain Terminologies and Abbreviations.  During the discussion on the Project Schedule and Project Milestones you will surely touch abbreviations and terms such as UAT, Parallel Run, Internal Testing, Uploading etc. Although these might be a routine to you it might be a totally new experience for some of them. Be sensitive to your audience by explaining briefly the purpose of the activity and it’s significance to the project.
  7. Present your Project Management Tools. These tools are equally important to the project. There are tons and tons of tools out there, from issue tracker, file repository, schedule monitoring, correspondence keeper and progress reporting. I could name a few in my future blogs and probably would recommend some. If you plan to use a Project Management tool that the customers need to use then this is the exact time to show and discuss it with them and highlight its advantages so they could understand its necessity.
  8. Emphasize Teamwork. The most important word in the whole project, stress clearly to them that your team and theirs is actually just one team and both of you needs to work together to achieve success of the project. In doing so and if they buy your idea, you can achieve cooperation between two sides.

You may of course add a few more agenda to the activity if you think it is necessary, always keep in mind that a wisely planned and well-conducted Project Kick-off meeting is the best way to launch a project. Just like they always say, first impression lasts.

Posted in Project Management | Tagged , , , , , , , , , , , , , , , , | 3 Comments

ERP Project Management: How to deal with uncooperative users

After years of implementing ERP projects I have dealt with an array of different users. The most challenging to handle are those who are uncooperative. Obviously.

Based on experience these types of users are usually those who have been in the company for a considerable number of years and very much comfortable with their current workflow.

Here are 8 tips on how to handle them effectively:

  1. Give Assurance. Make them feel assured with the new system. Always keep in mind that you are in some ways taking away their comfort zone, so a little assurance that your system is better that their current one could go a long way.
  2. Plan and Prepare. Make sure you got all sides covered as much as possible before you meet with them. Do your homework so you could address their concerns effectively. Plan all your activities specially those ones, which involves these users and let them know in advance, this way they could also plan their schedule and both sides will be on the same page. Uncooperative users normally tries to look for an excuse to be uncooperative don’t give them this opening.
  3. Be Confident. The users would be assured if you show confidence and to be confident you have to have everything prepared. Your aura of confidence will rub onto them, if they saw you as a tentative and unsure kind of person, they will feel the same way towards the project. On the other hand, your confidence gives them assurance that they are in good hands and everything will be all right.
  4. Never Lie. There is a fine line between convincing the users and lying. Never promise something that cannot be done just for the sake of getting their approval. Be truthful, sometimes all it takes is a single lie and everything that you worked so hard for could go down the drain. If it cannot be done just say so, if you have a workaround then make a proposal.
  5. Own your Mistake. In a huge implementation it is very difficult not to make mistakes. The important thing is how you accept and own yours and be able to smartly pick-up the pieces from there. The last thing you need in a project with unhelpful users is for them to discover a mistake you tried so hard to conceal.
  6. Communicate well. Dealing with other people always, always boils down to an effective communication skill. Listen intently and make sure you understand their apprehensions then speak in a mildly toned voice. They say that 10% of conflicts are due to difference of opinion and 90% is due to wrong tone of voice. Always bear in mind that conflict in a project will not benefit anybody.
  7. Ask for their opinion. Everybody wants to be heard period. In a situation where what you will decide on directly impacts another persons working habit, that person deserve to be heard; their opinion matters. In asking for their opinion you are shooting two birds with one stone; gathering information and making disobliging users oblige.
  8. Project an approachable image. Because a project implementation is a two-way street, there should be minimal or no room for uneasiness. You should let them know and feel that they can approach you and ask question anytime. Projecting an approachable image will encourage all types of users to liaise with you effectively.

Of course there are more things that you could do to deal with uncooperative users and make the project implementation become successful but most of them revolves around those I have listed above.

Posted in Project Management | Tagged , , , , , , , , , , , , , , , , , | Leave a comment