Beware of pitfalls that can sabotage your project

The greatest fear to mankind is the fear of the unknown. There is a term used in the software sales community that can also be used in the software consulting services profession. The term is FUD, which stands for Fear, Uncertainty and Doubt. During the sales cycle, it is the FUD factors that can help a second-place software solution take the lead. The same use of FUD factors can cause what starts out to be practical business decisions become the worst thing a company has ever tried to do. Poor ERP project cost estimation will be the demise of the best project team ever assembled and could cause the failure of the implementation. The current state of ERP project estimation is all over the scale -- from the most complicated formulas to "what do you think the client is willing to pay?" ERP project estimation falls along a relative scale of accuracy. Today project estimation seems to be somewhere between guesswork and random number generation. This isn’t to suggest that project estimation should be all the way to the left of the scale. But it certainly needs to be moved closer to predictable, or at least toward the center. By more accurately accounting for resources, tasks and potential pitfalls, companies can more accurately predict the cost of a project. Resource Estimation Estimating resources appears to be very straightforward. The project manager assumes two things: "I know my project budget, and I know my staff. Therefore, I know my project resources." Predicting the present is easy, predicting the future is difficult. By the time the project gets into full swing, your available resources may take a different direction than the path you planned. Just when you need a critical resource to configure the complex pricing algorithms, the trained subject-matter expert that you were counting on announces he has accepted a lucrative position with another company. What now? Even resource estimating has its problems. You must always consider the possibility of losing key resources and have alternative options available. These are pre-approved, secondary resources with the option to free them up from their current positions to fill in the project, if needed. On the reverse side, what if the project budget was cut by 30 percent? What resources could be cut? What resources would be able to take up the slack? After all, you will still be held responsible for completing the project on time? Cost Estimation ERP project cost estimating is sometimes like predicting the future, we don’t really believe in fortune-tellers, but we listen to them in amazement. Over the years I have taken classes and attended many seminars on everything you wanted to know about IT business systems and project management. The one thing they all had in common was the same basic philosophies and the basic formula: Hours x Rate x Complexity Factor = Cost. From that base, they all differed depending on the style and experience of the instructor. Why are ERP project cost estimates so intimidating? The mere mention of the subject reduces perfectly normal project managers to shuddering wrecks and sends fearless seminar instructors to an early departure to the airport. There are two reasons. The first is the failure to identify all tasks of the project. The second is the wrong estimation of the tasks that are identified. Failure to Identify All Tasks One of the most popular techniques for estimating the total cost of a project is to give a "rough estimate" to the steering committee and keep lowering it until the screams fall below the decibel level of a 10 hp chain saw. That’s the number we go with, after all, we don’t want the project canceled. Unfortunately, this leads to unrealistic, low-cost estimates causing team members to work unpaid overtime and weekends, cancel vacations and worse. In order to get a handle on ERP project estimating, you need to break down or divide the project into its smallest manageable tasks. The reason for doing this is to identify all of the tasks that may be over looked. Once all of the tasks are identified, along with their dependencies to one another, you will be able to calculate the cost. Unless you have done this a dozen times before, this is a difficult task in itself. Therefore, before the actual project work starts break the project into two major phases. The first phase is the "Scope or Blueprint." The second phase is the "Construction," or the implementation of the project. Scope or Blueprint This is the time you prepare the actual project estimate. I would even suggest this be done prior to software selection. The total project scope is planned and the actual estimate for the project is prepared during this phase. Each ERP project has its own unique objectives, scope and priorities. This phase identifies and plans the primary focus areas to be implemented. As you prepare for your implementation, there are important issues you must address at the beginning of the project, including: • Defining your project goals and objectives • Clarifying the scope of your implementation • Defining your implementation strategy • Establishing the project organization and committees • Identify all the tasks • Defining the project schedule and implementation sequence • Identifying and assigning resources By addressing these issues during this phase, you will be able to provide an educated and accurate estimation, eliminating the guesswork. This will help ensure that the project proceeds efficiently, and that you have established a solid foundation for a successful implementation. This phase is to create a Scope Blueprint document, which is the detailed documentation of the results gathered during requirements definitions. With this document, you achieve a common understanding of how the company intends to run its business within the new ERP system environment. Once you have obtained the signed approval from the executive steering committee, this will become the implementation budget. Remember a good estimate requires knowledge, time, effort and attention to detail. Preparing an estimate is a mini project in itself. For more detailed information contact John Ziegler at This e-mail address is being protected from spambots. You need JavaScript enabled to view it

Written by :

johnziegler