In most decisions involving your business you carefully scrutinize all of the important aspects. You review the business justification, the costs, the return on investment and the plan for implementation. Then, 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.
So why, when you’re implementing new systems that may significantly affect critical areas of your business, would you treat this differently?
Hopefully, when making the decision to implement new systems, you have sound business reasons and solid justification for doing so. After 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. When your key project team members are trying to perform their regular jobs plus learn and test a new system, they will be less efficient (and possibly even grumpy).
Once the decision is made to proceed, next comes the job of defining what you need. Some 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. Often nicely formatted, very detailed documents are generated to clearly articulate the specific requirements of each area. This 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. In an effective team, relationships will be strengthened and processes improved. This is good.
However, since this is a significant investment of time, and you feel you’ve described everything you know in great detail, there can be a tendency to say to the software implementer “go forward and make all of the approved enhancements, test them, then deliver the system and train us on how to use it.”
Hold that thought for just a moment…
In the final stages of proposing a system to a prospective client I am often asked this question: “How many projects have you managed on time and within budget?” Generally, my answer is about 40-50% which surprises some. I assume they expected to hear a promise of 80-90%. So this inevitably leads to the next question: “What are the most common reasons for a project going over time or over budget?” From experience I can confidently state the following reasons:
1. Scope increases are not controlled (by your project management team)
2. The wrong people are involved (your project team members)
Hopefully these reasons make sense. If scope increases are not controlled, the project begins to increase in size and complexity, increasing time and dollars. If 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.
I recently encountered a third reason for projects going over budget, a variation on the “wrong people” reason above:
3. The internal people are uninvolved (your key project team members)
You may be stretching your imagination to even consider this as a possibility. So I’m going to help you.
Let’s go back to a paragraph above (just before I asked you to “hold that thought”). Once your key project team members have made a significant investment of time and your requirements are approved and published, there can be a tendency to say to the software implementer, “Go forward and make all of the approved enhancements, test them, document them, then deliver the system and train us on how to use it.”
This sounds like a logical plan based on a traditional software development life cycle. After all, your key people have done their research, developed requirements and documented everything in great detail. They probably participated in many lengthy meetings as well. Now it’s the job of the software developer/implementer to build or modify the software to fulfill the requirements that your team so beautifully defined.
Before you decide to take this path, consider this crude example. Suppose you say to an inventor/developer, “Build a tool to open cans safely and easily.” You 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. Suppose the inventor/developer delivers a tool that looks like this:
It meets your requirements. It opens cans safely and easily. He has fulfilled his contract purely based on your requirements. Yet, you may not be pleased because it is not what you expected.
Example 2: Suppose the inventor/developer delivers a tool that looks like this:
It meets your requirements. It opens cans safely and easily. And yet, it does something completely different than the previous device. Instead 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.
Here’s a third (and final) example. Suppose 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. And 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. It still sounds good. It looks good too.
It meets your more specific requirements. It is electric, with a magnet and a button, and it opens cans safely and easily. However, in your business you have the need to open 5 and 10 gallon cans. They will not fit in this device. Again, you’re not satisfied because this still will not do the job.
There is a point to this can-opener analogy. The inventor/developer knows only what you tell him. Even if your specification stated all those details about the “electric device” 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. How can they?
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. In the crude “can opener” 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. Additionally, 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.
The can opener examples have very simple requirements compared to an integrated business system. Imagine the variations in the tools delivered when you consider the complexities of business software.
When embarking on a system project that may significantly affect critical areas of your business it’s important to develop close partnerships with all parties involved in the project. It’s 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:
- Builds project checkpoints (that occur early and often to make sure you are getting what you need and not what you said you wanted)
- Provides system knowledge to your key people
- Provides a vision of the system
- Builds relationships between the consultants and your key people
- Spreads training out over the life of the project
- Spreads testing out over the life of the project
With proper involvement, testing and “model office” sessions you will ensure that the system meets your needs, functions as expected, produces your desired results and your users know how to use it.
Get Involved and Stay Involved
A new system may not affect the physical product you produce or distribute, but it will affect the service you provide, the accuracy of your business information, the efficiency of your key project team members and possibly the profitability of your business.
You don’t want to end up with a system that fulfills your requirements but does not meet your needs.
You want to implement a system that meets your needs along with a team of users that know how to use it.
In a recent blog post about onboarding, the final line of a client success story stated, “By the time the system went live, very little training and support was needed, because users were already comfortable – and even anxious to begin using it.”
I think this is a statement everyone would like to make when their new system is implemented. Wouldn’t you?
