{"id":43211,"date":"2011-05-31T21:52:38","date_gmt":"2011-05-31T21:52:38","guid":{"rendered":"https:\/\/wp.lansa.com\/blog\/user-involvement-in-new-system-implementation"},"modified":"2025-05-08T03:27:07","modified_gmt":"2025-05-08T08:27:07","slug":"user-involvement-in-new-system-implementation","status":"publish","type":"post","link":"https:\/\/lansa.com\/blog\/app-development\/rapid-app-development\/user-involvement-in-new-system-implementation\/","title":{"rendered":"Implementing New Systems \u2013 Get Involved and Stay Involved"},"content":{"rendered":"

In most decisions involving your business you carefully scrutinize all of the important aspects.\u00a0You review the business justification, the costs, the return on investment and the plan for implementation.\u00a0Then, as the activity moves forward, you have your staff involved to monitor activities, track costs, provide information, ask questions and generally gain knowledge that will be beneficial as the project completes and you integrate new things into your business. This is sound and effective business management.<\/p>\n

So why, when you\u2019re implementing new systems that may significantly affect critical areas of your business, would you treat this differently?<\/p>\n

Hopefully, when making the decision to implement new systems, you have sound business reasons and solid justification for doing so.\u00a0After all, new systems usually incur large monetary costs, but they also incur significant costs in the investment of the time of your staff, time spent learning, testing and validating, plus the associated decrease in efficiency caused by working with a new and unfamiliar tool.\u00a0When your\u00a0key project team members\u00a0are trying to perform their regular jobs plus learn and test a new system, they will be less efficient (and possibly even grumpy).<\/p>\n

Once the decision is made to proceed, next comes the job of defining what you need.\u00a0Some companies will do a great job of gathering requirements from every area, including identifying flaws or shortcomings of the existing system that must be addressed in the new system.\u00a0Often nicely formatted, very detailed documents are generated to clearly articulate the specific requirements of each area.\u00a0This is a very worthwhile activity, and not just because it generates good requirements. During this process, people typically learn a great deal about their jobs, the jobs of their coworkers and how each affects the other.\u00a0In an effective team, relationships will be strengthened and processes\u00a0 improved.\u00a0This is good.<\/p>\n

However, since this is a significant investment of time, and you feel you\u2019ve described everything you know in great detail, there can be a tendency to say to the software implementer \u201cgo forward and make all of the approved enhancements, test them, then deliver the system and train us on how to use it.\u201d<\/p>\n

Hold that thought for just a moment\u2026<\/p>\n

In the final stages of proposing a system to a prospective client I am often asked this question: \u201cHow many projects have you managed on time and within budget?\u201d\u00a0Generally, my answer is about 40-50% which surprises some.\u00a0I assume they expected to hear a promise of 80-90%.\u00a0So this inevitably leads to the next question: \u201cWhat are the most common reasons for a project going over time or over budget?\u201d From experience I can confidently state the following reasons:<\/p>\n

1. Scope increases are not controlled (by your project management team)<\/p>\n

2. The wrong people are involved (your project team members)<\/p>\n

Hopefully these reasons make sense. If scope increases are not controlled, the project begins to increase in size and complexity, increasing time and dollars.\u00a0If the wrong people are involved, then questions may be answered incorrectly, design decisions may be made improperly and testing may be inadequate or simply incorrect.<\/p>\n

I recently encountered a third reason for projects going over budget, \u00a0a variation on the \u201cwrong people\u201d reason above:<\/p>\n

3. The internal people are uninvolved (your key project team members)<\/p>\n

You may be stretching your imagination to even consider this as a possibility.\u00a0So I\u2019m going to help you.<\/p>\n

Let\u2019s go back to a paragraph above (just before I asked you to \u201chold that thought\u201d).\u00a0Once your\u00a0key project team members\u00a0have made a significant investment of time and your requirements are approved and published, there can be a tendency to say to the software implementer, \u201cGo forward and make all of the approved enhancements, test them, document them, then deliver the system and train us on how to use it.\u201d<\/p>\n

This sounds like a logical plan based on a traditional software development life cycle.\u00a0After all, your key people have done their research, developed requirements and documented everything in great detail.\u00a0They probably participated in many lengthy meetings as well.\u00a0Now it\u2019s the job of the software developer\/implementer to build or modify the software to fulfill the requirements that your team so beautifully defined.<\/p>\n

Before you decide to take this path, consider this crude example.\u00a0Suppose you say to an inventor\/developer, \u201cBuild a tool to open cans safely and easily.\u201d\u00a0You may be envisioning an electric device where you place the can on the magnet, press a button, and in a moment the can is open.\u00a0Suppose the inventor\/developer delivers a tool that looks like this:<\/p>\n

\"Can<\/a><\/p>\n

It meets your requirements.\u00a0It opens cans safely and easily.\u00a0He has fulfilled his contract purely based on your requirements.\u00a0Yet, you may not be pleased because it is not what you expected.<\/p>\n

Example 2: Suppose the inventor\/developer delivers a tool that looks like this:<\/p>\n

\"Can<\/a><\/p>\n

It meets your requirements.\u00a0 It opens cans safely and easily.\u00a0And yet, it does something completely different than the previous device.\u00a0Instead of opening the entire top of the can, it just pokes a hole. You’re probably still not pleased because this is also not what you expected.<\/p>\n

Here\u2019s a third (and final) example.\u00a0Suppose you greatly improve your requirements to state that you want an electric device with a magnet and a button to open cans safely and easily.\u00a0And suppose the inventor\/developer creates an electric device where you place the can on the magnet, press a button and in a moment the can is open. It sounds good so far. It will handle cans of many sizes, covering all of the common sizes that are found in a grocery store.\u00a0It still sounds good.\u00a0It looks good too.<\/p>\n

\"Can<\/a><\/p>\n

It meets your more specific requirements.\u00a0It is electric, with a magnet and a button, and it opens cans safely and easily.\u00a0However, in your business you have the need to open 5 and 10 gallon cans. They will not fit in this device. Again, you’re\u00a0not\u00a0satisfied because this still will not do the job.<\/p>\n

There is a point to this can-opener analogy. The inventor\/developer knows only what you tell him.\u00a0Even if your specification stated all those details about the \u201celectric device\u201d one important bit of information was omitted, the size of the cans. No matter how detailed you get with your specifications, only your key people know your specific business. The consultants from the software implementer do not know your business as well as you do.\u00a0How can they?<\/p>\n

Going back to my initial statements, in most decisions involving your business you carefully scrutinize all of the important aspects, create business justification and are heavily involved through all phases of the project.\u00a0In the crude \u201ccan opener\u201d examples above, if your key people were involved from the beginning, then the variations of the tool being built from your expectations would have been identified very early on, reducing wasted time and cost.\u00a0Additionally, the consultants from the software implementer would have learned about this part of your business, would be better equipped to help meet your needs and the proper tool would be in place.<\/p>\n

The can opener examples have very simple requirements compared to an integrated business system.\u00a0Imagine the variations in the tools delivered when you consider the complexities of business software.<\/p>\n

When embarking on a system project that may significantly affect critical areas of your business it\u2019s important to develop close partnerships with all parties involved in the project.\u00a0It\u2019s also important to test the system with your key people and your business processes to ensure that your requirements are fulfilled and your needs are met. This must be done regularly, as the project proceeds, and has many positive effects:<\/p>\n