Key Beliefs

Structured problem solving/dispute resolution.

ERP implementations can be complex, expensive and if executed poorly can damage the business. As such, time should be spent up front laying out processes for decision making, problem solving and dispute resolution perhaps including an ombudsman role.

The nature of the project.

Risks and skill requirements vary based on the type of project so it is important to really understand the 'nature' of the project in advance, i.e., implementation from scratch, restructuring existing databases, data merge, filter and extract. We have seen year long projects with twenty consultants keying data into spreadsheets for bulk tables loads when there was already a mature, fully functional Costpoint database; in this case we believe the project was misidentified as an implementation when it was a fairly clean cut data restructure.

Anticipate the risks.

In many cases clients do not bother to really consider business risk, which means there is no way to develop appropriate contingencies and they are left open to surprises at go-live. Risk areas are part of the project plan development and risky items are weighted differently. This is a deep thinking, reflective step that may require input from outside of the project.

Process development.

In addition to the functional testing, the conversion process itself needs to be proven well prior to go-live. It must be repeatable and predictable. Ideally it is a checklist based execution from which most elements of human judgment have been removed.

Prove everything.

If it is worth doing it is worth proving it was done right. Every major section on the project plan needs to have a 'proof rule'. Until the activities in the step have been demonstrated, or proven, the milestone has not been completed. This is a way of thinking and should permeate the entire project.

Manage to the right plan.

We have seen project plans flawlessly executed but the project fails to meet a significant portion of the expectation. If the plan is wrong, or the steps do not prove that things are as you expect them to be, then the plan does not contribute to a safe go-live.

Ensure early visibility.

We should take great effort to bring issues to light as early as possible. As an example, if the project calls for a redesign of the chart of accounts, it would be appropriate to test the chart of accounts via financial statements and project summary reports prior to beginning the first formal test cycle.

Include weighted relevance on the project plan.

We have seen too many project plans where there are ten pages devoted to control screen initialization and nothing in the plan that indicates it is important to thoroughly test the billing. Tasks and milestones should be rated based on risk/complexity/critical path. It is not significant to be fifty percent complete if you have not demonstrated significant achievement during that half.

Technical and project management discipline.

Project management, and data conversion in particular, are not like most office jobs, in that they may lack the standard procedures present in most functions. They often require creative, yet structured, thinking.

• Home
• Experience
• Services
• Key Beliefs
• DATA MIGRATION TIPS
• CLIENT ACCESS
• CONTACT US