You are involved in a long-duration, complex project. So you need to make sure that all people involved understand the kind of activities they will be involved in. Core activities for any ERP selection and implementation project include: > Structured meetings > Structured note-taking > Structured document reviewing > Structured task management Key to these activities is 'process' and 'structure'. Projects where you do not have clearly defined and communicated project participation processes and structured procedures are likely to struggle.
You must be explicit about your billing policy i.e. how you want your project billed. So you need to make sure that your partner understands exactly what is expected from them as valid billing. You need to be very clear about: > Frequency - weekly or monthly? > Timesheets - provided or not? > Level - activity, session, track? > Resource identification - yes or no? > Resource identification - yes or no? You also need to be very clear about your expenses policy (see Expenses). Your project weekly reporting must be able to track billing to date so that these numbers are always easily available for reference.
ERP implementation projects demand proactive change management So you need to make sure that all people involved understand the impact of the project on their jobs and on the people that report to them. Change management involves: > Identifying the changes anticipated > Assessing the change impact on change stakeholders (impact mapping) > Re-defining roles & responsibilities > Communicating change to the right people at the right time > Reviewing change impact and role definitions post go-live Key to these activities is communication so that no-one is surprised by change when it is introduced into the business.
You must log all significant project decisions. If you do not log decisions, as the project progresses you will quickly forget who made that decision, when and why. Effective decision logging involves: > Defining what kind of decisions to log > Having a system to log them in (database or spreadsheet) > Logging what,who,when and why for each decision > Reviewing decisions made at steering team meetings Even if you do not log other decisions, you must log decisions made at steering team/stage gate meetings.
Most ERP implementations involve your IT people managing multiple environments. Depending on the complexity of your project this could include at least 3 environments: > Development or Dev > Test > Live The DEVELOPMENT or DEV environment is where code being developed (i.e. modifications/customizations) is worked on. When it is ready to be tested it is migrated to the TEST environment folliwng an agreed process. The development environment may be located 'offsite' i.e. under the management of your vendor or partner. The TEST environment is where code is tested (e.g. by key users) before it is 'accepted' and ready to migrate to the LIVE environment. The TEST enviroment will often include many variants of test companies. The LIVE environment is only needed close to and after go-live and is the environment used by the business when the system is put into 'production'. You should not use the live enviroment for any kind of testing as this introduces an unnecesary risk. Depending on the needs of your business and the specific ERP system in use, these environments may be: > Isolated as separate virtual machines (VMs) on one or more physical servers > Isolated on separate physical servers The other environment normally provided either by your hosting company or as part of your internal IT infrastructure is the Disaster Recovery (DR) site located at a wholly separate physical site from your LIVE environment.
An early implementation decision to be made is: Are you opting for a fixed cost or time and materials contract basis? Obviously there are advantages and drawbacks to both options. Considerations relating to fixed cost contracts include: > This may be your only option if your budget is truly constrained > You have to define very accurately what the fixed price covers to avoid wrangling later over deliverables > Fixed cost contracts may need to be subject to penalties and retentions and these have to be agreed with your supplier > Fixed cost contracts may need to be subject to staged billing that has to be agreed with your supplier Considerations relating to time & materials contracts include: > Significant risk that you can go over budget and exceed your delivery timeline > You have to define very accurately who your rersources are and what is the basis for the time and materials rates > Time and materials contracts are more difficult to subject to penalties and retentions > Time and materials contracts must have a clear 'cancellation without penalty' clause
Effective gap management is an essential project management skill in ERP implementations.
Many projects start with the laudable aim of 'no customizations' but end up having to manage lengthy gap lists.
Managing the gap list effectively is essential to keeping control of project costs and timeline.
Gap management involves:
> Identifying gaps
> Triaging gaps
> Developing gap fills
A gap defines functionality that is missing to enable you to move from an 'as-is' solution to the future 'to-be' solution.
Once identified gaps need to be efficiently 'triaged' - for example:
> Is gap a 'needed for go-live' or 'post go-live' gap?
> Who will fill the gap - the customer or the vendor/partner?
> Does the gap require development and if so how much will this cost?
The priority gaps to identify are those that are needed for go-live, require development and involve cost to the customer.
In order to manage these gap fills effectively you also need a robust development process since to develop the gap is a 'mini-development' in its own right and needs to be managed at gap, track or project level as a series of change requests.
Every project needs good habits and to establish routines. Many businesses are not used to the demands of an ERP implementation project and maintaining good habits and routines helps to make the transtiion to 'project-working' easier Good habits and routines include: > Weekly delivery team meetings > Monthly steering team meetings > Use of a shared project calendar > Sticking to meeting start and end times > Reading and responding to emails/calls in a timely manner Establishing and enforcing these habits and routines is a key responsibility of the project manager.
Everyone needs to be clear from the start: What implementation methodology will be used on your project? Every vendor/partner has a slightly different implementation methodology. As a customer, what you need to be sure of is that you understand it and that you agree with it. Most methodologies are a variant of the 5 'Ds' and involve a stage-gate at the end of each phase: > Definition > Discovery > Development > Delivery > Deployment Definition is the pre-start step of defining the what, why, who, where, when and how/how-much/how-long of the project. This is usually encapsulated in a project initiation document or PID. Discovery involves the analysis and documenting of requirements - what is needed to get you from 'as-is' to 'to-be'. Usually the discovery output will form the basis for the statement of work. Development involves the development, testing and acceptance of: Gap-fills, interfaces and integrations, major add-on modifications etc. Delivery involves the testing of the solution so it can be signed off as delivered and ready for deployment into the business. Deployment involves the training of users, and the pre go-live and go-live activities. There are normally 2 post go-live phases: Stabilization and Optimization.
Implementation projects can be long and stressful for the participants - especially those in the delivery team. So you need to build some kind of reward system into the project to help keep people motivated. This is especially true if your project team members are holding down both their 'day' job and their 'project' job. Examples of junkets and rewards include: > Offsite meetings where some down-time can be included > User-day, conference or trade show junkets > Branded project 'trinkets' - Polo shirts, pens, laptop bags etc. > Stage & end of project events e.g. meals or barbecues > Stage & end of project bonuses
Kickstarts are needed at various points during a selection or implementation project. They should be designed to energise teams and ensure that they to go into the next project phase fully informed of their roles and responsibilities . Kickstarts are needed: > At the start of selection and implementation projects > To initiate any major project phase (e.g. UAT) or change of direction > When the project seems to be 'flagging' for any reason
You need a license log to keep track of licences. Keeping track of software licences and their annual maintenance/support start and end dates is an essential asset management task on an implementation project. The number and value of licences can increase quickly in an ERP implementation, for example: > Server licences (e.g. MS Windows) > Database licences (e.g. ORACLE) > ERP full and limited user licenses > 3rd party add-on licences > API and mobile licences All of these licenses will likely be subject to differing annual maintenance and support costs that come into play at different start and end dates. Understanding when maintenance and support contract start/end dates fall is essential to planning for meeting the ongoing OPEX costs of your ERP system.
You will do a lot of meetings in an ERP selection or implementation project. So you need to make sure that your meetings are planned and executed as effectively as possible. By meetings, I include: > Face-to-Face or conference call meetings > Demonstrations > Reference site visits > Attendance at seminars or training courses Your meeting communication should be consitenctly structured to clearly answer these FAQs: > Who is expected to attend? > What is the meeting about (agenda)? > Are there any meeting pre-requisites e.g. documents to read? > What do attendees need to bring with them e.g. a laptop/tablet? > What are the expected meeting outcomes or deliverables? > When is the meeting scheduled for? > Where is the meeting located? > Will breakfast/lunch/dinner be provided? Project team members are always busy people. By structuring every meeting invite in this way, people can quickly scan your email to understand everything they need to know. All project meetings should be scheduled in the shared project calendar. The most important post-meeting communication is what needs to be actioned by whom and by when - in other words the task output.
You never know when you might need it - always keep a narrative log. A project narrative log is simply a list of all significant events listed in date order. Narrative events may include: > Key Meetings and calls > Important emails (attach a copy of the email) > Important documents (attach a copy of the document) > Decisions Yes, you may be able to find a record of these events elsewhere in your project management system. But keeping everything in a single log, and updating it as you go, just makes things a lot easier when you are asked to replay a series of events from the project past.
Optimization is a post go-live phase that comes after Stabilization. Once your solution is stabilized after go-live then your project moves to the optimization phase. Optimization involves: > Post stabilizatiion review > Identification of process optimizations > Identification of role optimizations > Identification of functional optimizations > Execution of optimization changes and developments e.g. new gaps In my view, optimization is the final stage of an ERP implementation project.
You will most likely have more than one partner involved in your ERP implementation project. So managing your partner relationships is a key skill, especially for the project manager. You with each partner, you need to be very clear about: > Your billing policy > Your expenses policy > The issue/problem resolution process > Your contract terms and conditions > Your statement of work > Your partner's implementation methodology > The roles and responsibilities of their people on the project Now whereas you are unlikely to change your main ERP app during implementation, changing the partner supplying that app, is much more common. Obviously this only applies when you are buying your main ERP app via a reseller channel, rather than direct from the vendor. So you need to be prepared. You should be very clear - from the start - about the process for and consequences of terminating your partner relationship, for example: > Is there a formal process to 'switch' partners? > What is the termination notice period? > Are there any possible penalties resulting from termination? > Does an arbitrator need to be involved? > What legal system governs your termination (yours or that of your partner)?
Every development - no matter how small - must be delivered with a release note. A release note is essential documentation for any development and should include: > A description of what was delivered, when and by whom and for which application version > Screenshots from the application (e.g. user interface or code listing) of what is delivered > List any existing objects (codeunits, reports, tables etc. ) modified > List any new objects created/deleted > State if the code will sit inside or outside standard code (for upgrade purposes) Release notes are essential for 'checking-off' that developments have been delivered to specification and for facilitating acceptance testing and signoff.
Scoping is a vital part of the Project Initation Document (PID). Scoping changes should always be subject to a formal steering team process and decision as 'scope-creep' is where much complextity and cost can be added to a project. Your scoping definition should include both business scope e.g. business units included and functional scope. You functional scope should be clear about: > Is a function/process/module in or out of scope for go-live? > If out of scope is it in or out of the post go-live programme roadmap? > When scope changes were decided, by whom and any change requests linked to this decision
Task management is a vital skill for all participants in ERP projects - especially those in the delivery team. Without effective task management it can be very difficult to move the project forward and in my experience, many people do not like to be task-managed and either resist it or are not good at it. Effective task management demands: > Clear communication of what task management is and project management expectations > Using a very simple and easy-to-use task management system > Paying constant attention to outstanding tasks at all kinds of team meetings > Escalating poor task management by individual team members to the steering team
Usability is a highly underrated criterion in ERP selection and implementation projects. Usability is a function of the user experience of the software which is also partly determined by the look-and-feel of the application. Usability criteria are often minimized in selections or not considered worthy of spending money on as gap developments in implementations. But paying attention to usability pays dividends: > It helps to reduce the application learning curve > It helps to reduce errors > It helps to highlight items of importance or what to do next > It helps to make 'living-in' the ERP system easier for heavy users > It provides functionality to 'personalize' applications to user needs
It often seems like a no-brainer to opt to buy a vertical module vs. customizing standard functionality. But this decision needs to be carefully considered for these reasons: > Vertical license fees can add up fast > You are likely to be more 'locked-in' to the vendor supplying the vertical module > You are likely to be limited in how the vertical module itself can be modified - e.g. your needs may not fit the vendor roadmap and will be resisted > If you fall out with your partner, you could be left with a vertical module that other partners will not support > Just like customizations of standard functionality your vertical module functionality may gradually be replaced by future vendor upgrades
ERP selection and implementation projects are full of workshops, for example: > Requirements or discovery workshops > Playback or walk-through workshops > Training and testing workshops So managing workshops effectively is a key skill since they can embody much of the cost of a project. A single 1-day workshop involving 5-10 people can in effect be costing the project £5-10K. Therefore you must be very clear about expectations both with vendors and workshop participants: > What needs to be done pre-workshop (pre-requisites) > How the workshop session is managed on the day and the outcomes expected > What needs to be done post-workshop