Author Archive

Successful project implementation is the result of having the right project processes, tools and organization. If the project setup has been done correctly (see our recent post on project setup), then any issues that arise during implementation should be relatively easy to correct.

Key project processes usually revolve around status reporting, so project managers can determine if a project is on track. The status meetings will typically be at two levels: one internal within the project, likely held weekly, and one summary meeting at the executive level held monthly.

The internal meeting should focus on whether the milestones identified in the project plan are being hit, whether the right resources are being made available (critical for part-time resources) and whether there are any new requirements (scope changes) that need to be addressed. The executive summary meeting will typically focus on high-level milestones, such as business risks and especially cost projections. If the correct project setup has been completed, both status reports can generally be concise “red light, green light” documents rather than lengthy descriptions.

The project tools will usually include a tool to capture task status and display in the form of a Gantt chart. To keep these tools up to date during implementation requires some level of discipline. If they are used for resource tracking as well as schedule tracking, they require time capture by the project team, which is typically a tough culture change for mid-size organizations. At a minimum, it is recommended that the task status be reflected using simple 0% (not started), 50% (started) or 100% (completed) choices.

For the project organization, the critical aspect is identifying the business responsibility of any strategically important project. It’s very common for an organization to appoint a project manager from the IT department but leave the business responsibility fuzzy. Ideally there is a joint responsibility between IT and the business, with the key players including the success of the project on their performance evaluations.

For any project, the first step towards success is recognizing that it needs to be planned out. The goal of this early phase is to ensure that all parties have a common set of expectations for the project and that the appropriate resources have been allocated. It’s very tempting to jump straight into implementation once a new technology has been identified that could benefit the company, but the risk of some failure during execution is high in this case. It’s completely appropriate to run a brief trial or pilot phase to test out assumptions, but it should be very clear from the outset that this does not represent the final rollout.

The first priority is to get an agreement between the affected business departments and IT on the goals of the project, and to set expectations on what can realistically be achieved. This is challenging in two dimensions. First, it’s common for the IT department to have trouble communicating in a way where the business really understands IT’s intentions. Technical jargon frequently gets in the way. Second, it’s easy to underestimate how much effort is required if a business process will change as a result of an IT project, especially if the process touches external customers. It’s a common assumption that implementing a particular software package will automatically result in some kind of best practice, but this typically isn’t the case.

The second priority is to hammer out the scope of the project in detail. It’s easy to miss this step in the rush to get into design decisions, but this is where cost control starts. Many cost overruns result from scope creep, small additions to the project made without explicit authorization until the project ends up being much bigger than originally budgeted.

The third priority is to build an implementation plan. At a task level, IT projects are notoriously difficult to model because tasks typically don’t have concrete dependencies the way that, say, construction projects do.  In IT projects, typically tasks have a finish-finish type dependency (i.e. one task can’t complete before another task has completed), rather than a start-finish dependency. The happiest medium is to at least try to define tasks so that each task is approximately two person-weeks of labor. Much more than this and tasks become hard to track. The resource plan is arguably the most important part of the plan. The timeline will be meaningless unless internal resource requirements are understood.

One final thought on project setup and planning: It should be part of a company’s culture that it is okay to cut or postpone a project at this stage. If the planning shows that the risk is too high or the resource requirements too burdensome, this is the cheapest time to cut the project. If projects are regularly cut during implementation it is a symptom of incomplete project planning.

Next step: See our post about ensuring a successful project implementation through the right processes, tools, and organization.

An ERP (Enterprise Resource Planning) system can bring significant benefits to your organization. The integrated nature of the system reduces double entry of data, improves visibility of information throughout your organization and can speed up key processes.

ERP systems pose a significant challenge to implement though, especially in mid-size organizations which are not able to dedicate full time resources unlike the large multi-nationals.

Successful implementations typically have several characteristics in common:

1. Understand the business drivers for change.

It is very tempting to start an ERP selection or implementation without a complete understanding of why you are making the change. A lot of companies will have generic criteria that push them into starting a project – such as “our current system is too old”; then part way through the implementation when things are tough they kill the project because there is not a strong enough business case for going forward.

It is always worth exploring, documenting and quantifying the case for change. This will drive much of your design and help you keep costs under control. And, if you can’t quantify the benefits, there is a strong chance you won’t achieve them.

2. Keep the ownership of the change within the business, not just IT

There is a significant IT component to any ERP project. But you can’t  outsource the whole implementation to IT and expect to get the benefits. There will be some level of business change associated with any integrated system and only strong business ownership can push these changes through.

Make sure you have a steering committee that includes senior business leaders and ideally include the project objectives on their performance appraisals.

3. Understand the 80:20 rule to cost and complexity

Whenever you try to select a new system, you have to make some assessment of the level of fit to your organization and processes. Generally, once you have found a vendor with a reasonable fit for your industry, you will typically be able to describe the fit as somewhere near to 80%. At that point, a lot of companies make a general statement such as “we will change the process to fit the software” or “we will pay for the customization that we need” and then move on.

Take the time to understand in depth that missing 20%. It will be very easy for that 20% to end up driving 80% of your effort, angst and costs during implementation. It is particularly true of any process which touches your customer.

4. Define up-front the selection criteria for a vendor

It is important to understand the functional fit of any one particular software package. But once you are down to a short list of 2-3 vendors, functional fit may no longer be the key deciding factor in settling on one favorite vendor. Other key factors will include level of support and training; availability of user groups; technical architecture; attitudes to customization and financial stability of the vendors.

Take the time at the start of the project to define the key factors for your organization and their relative importance – don’t wait until you are already through all the demos. These factors can help you get to a short list quickly and make your selection process much more efficient.

5. Ensure strong project and vendor management

Many organizations don’t have the skills or capacity to focus on the project and vendor management that is necessary to shepherd a successful implementation. Any vendor will provide some level of project management, but those resources are only focused on the tasks that the vendor will perform.

You need to make sure that there is someone focused on advocating for your organization in project meetings with the vendor and also managing the resources internal to your organization. Make the investment to get this help externally if necessary.

6. Develop a strong scope management process before and after implementation

Finally, we have all heard about the runaway projects which either get cancelled or implemented late or way over budget. A critical factor in keeping things on track is to keep a tight rein on scope. Once you understand more about what any software package can do it will be very tempting to keep adding new processes and reports into the project scope until one day you realize that you have a much bigger project than you originally defined.

Hold tight to the business case that you developed at the start of the project – only include those items which drive the business benefits that you are striving for. Everything else can wait until later – and then needs to go through its own justification.