Skip to content

IT Project Tip #17: System Test #1 | Conference Room Pilot

In last week’s tip, I offered 4 tips to help you manage the walkthrough presentations in your ERP implementation project.

In this week’s tip, I walk you through the first in a series of IT systems tests: the conference room pilot (CRP).

Tip #17: System Testing #1 |Conference Room Pilot

In the CRP test phase, your job is to make sure that the IT system is capable of handling the most probable business scenarios – for each and every functional department.  As you may recall from Tip #11, these high-probability business scenarios are called the 80% scenarios.  Once these scenarios have been adequately tested, the remaining 20% scenarios are introduced in a more comprehensive testing phase – the departmental pilot phase (discussed in next week’s tip).

Fulsome CRP testing of the 80% scenarios is a time-consuming project phase.  On average, we allocate two weeks to our clients’ CRP phases.  In some cases, the CRP can take as long as three weeks to complete.  The core team members participate directly in the testing.  Their participation provides them with an important element of hands-on training.  During the CRP, the core team is responsible for completing 6 discrete tasks, as follows:

1)      System Parameter Settings: IT system parameter setting need to be adjusted to reflect the changes that resulted from the walkthrough presentations.

2)      Update Business Scenario Lists: The business scenario lists need to be updated to reflect changes that resulted from the walkthrough presentations.

3)      Prepare 80% Scenario Scripts: Each and every 80% scenario must be translated into user instructions detailed to the field level of the IT application.

4)      Test the Scripts and Scenarios: Scripts and scenarios are to be tested in the system for validity (re-run to test major adjustments) using a set of test data.

5)      Refine Business Model and Blueprint Whitepapers: These need to be amended to reflect any changes that result from the testing.

6)      End-to-End Pilot: A test should be conducted to trace a single transaction through all departments.  This task tests all inter-departmental hand-offs and tie-ins.

The CRP and subsequent testing phases are designed to ensure that the redesigned business processes are synched with the systems configurations.  In all cases, both will likely need to be modified to reflect the results of the testing.

In next weeks’ tip, I discuss the departmental pilot phase.  In this next phase, we introduce a new set of users to re-validate the 80% scenarios and to test the 20% scenarios.

Your R.E.Q.s (Relevant Experience and Questions)

Are you invovled in the testing of ERP or IT systems? If so, we would love to get your feedback and/or thoughts on the following:

1) What CRP methodology have you used or been involved with? What are the strengths and weaknesses of that methodology?

2) Which part of your CRP consumed the most time?

3) What was the biggest challenge in your CRP?

Posted in Implementation Projects.

Tagged with , , , , , , , , , , , , .

No comments

By jonathang – August 31, 2010

IT Project Tip #16: 4 Steps to Walkthrough Presentations

In my previous tip, I broke down the 6 key elements of a change management plan, including the training plan.

This week, I discuss the 8th ERP project deliverable: the walkthrough presentation.

Tip #16: 4 Steps to Managing Walkthrough Presentations

The walkthrough phase is analogous to a play rehearsal.  The core team members are the actors and each department’s “to be” workflows collectively represent a play scene.  The project manager takes on the role of play director.  His job is to make sure that the core team members do effective workflow presentations and that each workflow (or scene) transitions well to the next.  In other words, the project manager is responsible to ensure two goals, as follows:

  1. That each department’s core team members effectively demonstrate to the rest of the core team how the new IT system will be incorporated into their respective department’s workflows; and
  2. That departmental choices relating to business processes and systems do not conflict with the choices made by other departments.

To achieve these dual purposes, we recommend the following 4-step structure to walkthrough presentations:

  1. Preparation and Delivery: The focus here is on business processes, not on systems training.  Though some system screenshots will inevitably be necessary, the bulk of the presentations should focus on the “to be” process flows.  In terms of preparation work, the substance is largely derived from the “to be” process maps as set out in the blueprint whitepapers (read my tip on blueprint whitepapers here).
  2. Workflow Approvals: The entire core team is responsible for approving the workflows of each functional department.  A full team approval process helps the team reduce the number of potential inter-departmental conflicts and helps it to identify missing inter-departmental process tie-ins.
  3. Blueprint Whitepaper Updates: The blueprint whitepaper drafts need to be revised to reflect the changes made during the walkthroughs.
  4. Gaps & Issues Database Updates. The Gaps and Issues Database needs to be updated to reflect any unresolved issues that become apparent during this phase.

The Walkthrough Presenetation is the first time that the project team has rehearsed the “to be” process flows.  This rehearsal, however, was still entirely based on the theoretical materials contained in the blueprint whitepapers.  No testing on the system has yet been done.  Not to worry.  With the completion of the walkthroughs, the project team is now ready to move from theory to reality.

In next week’s tip, I will drill down into the conference room pilot (CRP) phase; the first of three testing phases.  In the CRP, the core team will test the most frequently used business scenarios on the actual IT system.

Remember: if you have any questions about the Walkthrough Presentations in particular or on your ERP implementation project in general, feel free to reach out.  We’re happy to help.

Good luck with your IT projects!

Posted in Implementation Projects.

Tagged with , , , , , , , , , .

1 comment

By jonathang – August 17, 2010

IT Tip #15: Change Management Plan | 6-Stage Surgical Approach

In my previous tip, I identified potential pockets of change resistance and discussed how an effective communications plan can diffuse potentially fatal project resistance in an ERP implementation project.

This week, I break down 6 key elements of a change management plan, including the training strategy.  The change management plan completes the fourth and final deliverable in the project mapping phase.

Tip #15: Change Management Plan | 6-Stage Surgical Approach

One of the biggest hurdles – and arguably the biggest hurdle – in any IT implementation project is meeting the people challenge.  It is a multidimensional issue that oftentimes requires new job descriptions and new people.  Also, it often calls for a redrafting of the organizational chart.  At the end of an IT implementation project, your employees may find themselves working with new people, reporting to different managers and, in some cases, calling a new facility “home”.

Transitioning employees to the organization’s new state is complex.  Time and geographic project constraints magnify this complexity.  For example, one of our clients will soon be implementing ERP at four North American facilities, seven North American satellite offices and one China-based facility.  The employees in two of the major facilities have never worked on a modern-day ERP system and, as a result, require significant training.  Notwithstanding these constraints, all training must be completed before the company cuts over to the new system in 2011.  In this case – and in all cases – effective change management will largely depend on execution of a well-conceived change management plan.

The change management plan should provide a detailed, actionable roadmap to the desired future state.  We advocate a planning approach similar to the one used for business process mapping.  Specifically, the change management plan should be based on an analysis of the gaps between the “As Is” and “To Be” environments.  Given time, cost and geographic constraints, the path to change should also be the shortest, most surgically-precise path.  A change management plan should contain, at a minimum, the following 6 components:

  1. Gap Analysis.  Analyse “As Is” to “To Be” gaps in skills, jobs, structures and personnel
  2. Job Assignment: Assign individuals to the “To Be” jobs
  3. H.R. Alignment.  Create new job descriptions, plan employee transitions and begin the recruitment process.
  4. Communications Plan.  Develop a plan to notify existing employees of changes and provide them with a forum to communicate feedback.  Develop a plan to broadcast recruitment needs.
  5. Training Strategy and Budgets: Determine whether training is to be delivered using in-house or outsourced resources.  Consider geographic, time and other physical constraints.  Budget costs, including those relating to materials, time and travel costs.
  6. End-User Training Programs: Draft fulsome participant lists, training schedules, training plans and training effectiveness assessment reports.

At this point, your organization has mapped how it intends to transition to its future “To Be” environment, from both the process and people perspectives.  You are now ready to have your project teams move onto the next project phase: the walkthroughs.

In next week’s tip, I will offer tips on how to lead the walkthroughs – the phase during which the core team members demonstrate how their respective departments intend to use the software.

Remember: if you have any questions about your IT project, feel free to reach out.  We’re happy to help.

Good luck with your IT projects!

Posted in Implementation Projects.

Tagged with , , , , , , , , , .

No comments

By jonathang – August 12, 2010

IT Project Tip #14: Change Resistors and Change Management

In last week’s tip, I explained how to build a Gaps and Issues Database to keep ERP problems from torpedoing your ERP implementation project.  This week and next, I delve into the fourth and final deliverable of the project mapping phase: the change management plan.

This week, I identify potential pockets of change resistance and discuss how an effective communications plan can be used to diffuse potentially fatal project resistance.

Tip #14: Identifying Change Resistors and Managing Change

Having completed the blueprint whitepapers, you should now have a fairly good idea of what your business’ future operating environment will look like.  With this new-found clarity, it is time for you to lead your organization into the future.  This stage of the implementation project is all about leadership.  It is where the great project managers separate themselves from the pretenders.

To earn a spot in the “great project manager” category, you need to first secure project support from key stakeholders.  If key stakeholders won’t support you or the project, you can be sure they won’t follow you down a path that they perceive to be treacherous.  In fact, many resistors will hold the project back; in some cases sabotaging the project.

To secure stakeholder support, you first need to identify potential pockets of resistance.  Resistance can lurk throughout all organizational ranks.  Common examples include:

  • A union that objects to revised job duties that fall outside of the collective agreement;
  • Employees who are afraid of or do not want to learn new processes and systems;
  • Managers who object to donating their “A-players” to the implementation team; and
  • Executives who stand to lose performance-based incentives because of short-term disruptions caused by the implementation project.

Once potential pockets of resistance are identified, a customized strategy must be developed to convert resistors into supporters.  If conversion cannot be achieved and if the resistance is sufficiently strong, the project manager should consider the following worst-case scenario alternatives: recommending employee dismissal, recommending project termination and resigning from the project.

Oftentimes, however, resistance can be overcome.  In many cases, resistance results from a fear of the unknown.  As a natural defence mechanism, the human mind has a tendency to play out worst-case scenarios in circumstances of uncertainty and lack of information.  A communications strategy designed to provide information and address concerns can be an effective diffuser of project resistance.

A communications strategy should be set out in a comprehensive communications plan.  This plan should codify the procedures and responsibilities relating to the periodic dissemination of project-related information.  Key target audiences include: project teams, employees, and external stakeholders.  Examples of common communications channels include: email newsletters, press releases, meetings, town halls and analyst interviews/earnings calls.  Although one-way communications are important, two-way communications also play an important role.  Two-ways channels like town halls and departmental meetings open up opportunities to engage stakeholders who want their voices to be heard.  Oftentimes, these stakeholders bring to light key project-based issues that may have been overlooked.

Remember: good leaders listen.

You won’t want to miss next week’s tip.  In it, I will offer tips on how to develop a plan to deliver training to different people in different locations, all in a compressed schedule.

Finally, if you have any questions about your IT project, feel free to reach out.  We’re happy to help.

Good luck with your IT projects!

Posted in Implementation Projects.

Tagged with , , , , , , .

3 comments

By jonathang – July 30, 2010