We're a little late with this August issue due to vacations - but it was worth the wait!. In the July issue of Innovative Thinking, we talked about the challenges of Change Management and its impact on a successful ERP project. This month, we continue our ERP Done Right series - with a discussion of GATHERING BUSINESS REQUIREMENTS. Put your ERP Done Right articles together and you'll have a cookbook for great ERP results. Don't miss a single issue!
Gathering Business Requirements - Don't Let The Basket Get Too Full! By Paul Sita, Principal, Innovative IT Consulting, LLC. Paul can be reached at 631-549-1685 or email@example.com.
A daunting task. Gathering business requirements is a time consuming and frequently dreaded task among consultants and project leaders. For an ERP project it can be daunting, given the fact that ERP implementations are so broad in nature. Where do you start, and more importantly where do you end?
Exactly what is a requirement anyway? Sounds simple. But don’t confuse a requirement with a feature. A requirement is a statement of something very specific that you need the software to do. And in many cases, it’s not just THAT it does it, but HOW it does it.
For example, if you need multi-language capability, the requirement might be stated as “Need to be able to run the system in 5 languages simultaneously, with the logon of the individual determining the language in which the system is operating for that user.” This is a good requirement because it is very specific, 5 languages simultaneously, plus it says something about the HOW, namely controlled by the user logon.
Where do you start? Start in those areas that you know are either most unique or are the areas in which your organization faces challenges. If that’s order entry, start there. If it’s sales and pricing, start there. Requirements starts with interviews that we call Discovery sessions. These are 2-way conversations designed to uncover what may be unique in some way, and/or represent key business processes.
Don’t attempt to capture the requirements during the discovery session. Just keep notes. When you review the notes later, you should be able to identify the requirements arising out of the session. If at all possible, have two people at the discovery session, one asking the questions, and one taking the notes. If you do it this way, I guarantee you won’t miss much – assuming you’re listening!
Where do you end? After you finish the critical and/or problem areas, you’ll find that either you start hearing the same things over again, or that the kinds of things you’re hearing are fairly mundane and likely to be handled by any ERP system. While some of these requirements may be added to “round out” the list, don’t get hung up on them, as they will likely be touched on by any vendor that is selected for a demo.
How should I organize my requirements? There are 2 acceptable ways – either by business process, i.e. Order to Cash, or Procure to Pay, or by functional area. We prefer the process approach, since software vendors differ in how they define the functional areas.
How much is enough? Every organization is different in this regard. However, we find that except for the most complex situations, 10 pages or less is needed to really focus in on what’s unique and most critical. Less is really more, as it will help focus your discussion with both users and vendors alike.
You’ll be amazed at how quickly you can sort through competing solutions with a good set of requirements!
What is the status of your IT Project?
By John Pellegrino, Principal, Innovative IT Consulting, LLC. John can be reached at 631-549-1685 or firstname.lastname@example.org.
This month I continue my series of tips on project status meetings. This tip will focus on the project status report, which for some project managers is treated as a “dirty” word. However, if you don’t want to get asked the question in the title of this tip every day, or worse, every hour - this tip is ESSENTIAL! I have seen many project managers scramble when asked this question, sometimes in a panic. If you are doing a report and sending it to the correct people they will know the answer without asking you.
There's no time like the present..
The best time to produce the report is soon after the status meeting. This means the same day, or at worst, early the next day. After all, the best time to record any results from a meeting is when it is fresh in your mind. A common mistake of many project managers is to produce the report just before the status meeting. However, this document is not meant to communicate the status to the team
Don't build a "house of cards". Establish a structure to the report that works for the particular project. This can vary depending on the size and nature of the project, but in general it should have three basic sections.
- 1) It should list the accomplishments that were made since the last meeting.
2) It should list the activities for the team members to work on before the next meeting, including who is responsible for that activity.
3) It should list any issues that are awaiting resolution from people not on the project team.
Use it or lose it. I have one last point on the status report topic. The report generated after the previous meeting must be used as a working document of items to discuss at each project status meeting. This allows you to stay focused on what the team should be discussing, but that’s another tip for another time.
The Question of the month!! See below for our newest feature. Every month we will field a question from one of our fearless readers! Don't be shy. Submit your hardest question and see how we do.
Word Scramble time.
“One Characteristic of a good business requirement.." (2 words)
_ _ _ _ _ _ _ _ _ _ _ _
S F V I E I Y R P C C E
Answer to last month's word scramble.
“ The process of dealing with the various impacts of an ERP project." (2 words) (CHANGE MANAGEMENT)
Question of the month. This month's question comes from Carl H. in Hauppauge.
How can I convince top management that its' time for an ERP initiative? Carl, this is not a simple answer! But if any one point is critical - it's that ERP is NOT an IT initiative. ERP has to be driven from and justified from A BUSINESS PERSPECTIVE. So, the first step is to form a small ad hoc committee. Don't start by trying to justify ERP. Start by looking at areas of opportunity and improvement within the company and see if those areas might be improved through an ERP system. If the answer is yes, you'll be well on your way!
In September we'll continue ERP Done Right when we discuss Implementation Strategies.
We want your feedback. Contact us