“Bob”.

And Bob worked on their solution.  He was always there to add functionality or resolve issues. But then Bob died suddenly of a stroke or heart attack or cancer or being hit by a bus.  Or, to put a more positive spin on it, won the billion dollar PowerBall lottery and moved to Tahiti where he is now sipping frothy rum drinks out of a coconut.  Even in the case of the gentleman who had cancer, he thought he had 6-9 months and was gone within 3 months.  Far too ill to worry about the software support.  He truly did the best he could, but it wasn’t enough.

These poor fellows left a complete mess with their clients. Unintentional but a crisis nonetheless; causing these companies to call us in a panic. “Can you help us?” Of course, the answer in all things technical was “Maybe. It depends.”

Turns out, we could, and did, help these companies, ultimately writing an entire custom business solution for each of them. But there were several painful lessons.

1. Going with the proverbial one-person-show – While there are wonderful, well-intentioned developers out there who do a great job, the danger is always that something horrible may happen to them, as in the case of our clients. Or maybe something wonderful like a winning Powerball lottery ticket. Although in the case of the latter, one would hope that there would be some time for a hand-off of information and processes. Regardless, your business likely cannot run efficiently or even at all without your computer systems. You wouldn’t have the operations of your entire company held solely in the palm of one person, so please don’t put your information systems in such a precarious position.
2. Maybe not bleeding edge, but at least in the current decade – It’s extremely difficult and time consuming to stay on top of the most recent technologies. This is especially true when you are the only one doing all of the work, leaving little time for research or attending classes, etc. In a team environment, people do research and share it with their colleagues and often have lively “debates” (well, sometimes actual arguments) around the topics. Regardless, it opens up everyone to new ideas and methodologies. Working alone, and I am speaking from first-hand experience, is a very lonely time and doesn’t leave you much opportunity to gain exposure to new ideas and techniques which benefits your client in improved systems and streamlined methodologies.
3. You are NOT stuck with the situation – Often when we’re called in, the company says they felt “stuck” because the one person knew so much about the systems and they felt that they needed to retain the relationship, if only to show loyalty. That is a fallacy. There is no system that can’t be figured out although it may be an expensive undertaking. We have had multiple situations where we’ve not had any help on the system functionality and code and we’ve managed to work our way through it. Sometimes there is “documentation” comprised of some old dusty notebook printed on green-bar paper (remember that?) that hasn’t been updated in 20 years. Be aware that your company isn’t ever “stuck”. If you are working with a company or person that you’re not happy with, you can always change the situation. Find someone to work with that you like and trust.

So, don’t let your company get into a situation with one person holding the keys to your information systems. This can happen in companies of almost any size.  No one is irreplaceable and, if they are, you likely aren’t paying them enough. Get someone else brought up to speed, whether it’s internally cross-training the team or bringing in a consulting group like InTune to help. It doesn’t have to be perceived as a threat to “Bob” and, who knows, he may live longer if he’s not under so much stress.

Long live Bob…. And let’s hope your company survives it.

The post Alas, Poor Bob – The Weakest Link appeared first on InTune.

Final Changes:

Remember that you can make changes at any time to your software application. Thisexibility is one of the most advantageous aspects of a custom software application. You can work with your consultants to make sure that you get the application that you need and that the application will make your business cost effective and efficient. That said, remember that the later in the project that the changes are made, the more it will cost in both time and schedule. At the end of the software project, the only changes you should be making are bug fixes to the system. If you decide to make a major change, you need to weigh the cost in time and money against delaying the final implementation of the system.

Installation of Final Software:

Some applications, especially small applications, may not need an installation of final software, but rather, the version of the software that was installed during the beta software installation phase can be used. This occurs when any final changes made to the software can be made directly to the version that is already installed at your site. In other cases, a new and final version of your custom software application is installed at your site. This version may have additional changes and features that were not included in the beta software version. Once the final software is installed, and your employees are trained, you are well on your way to using your custom application to achieve your business goals.

Ongoing Support:

You may choose to maintain your system yourself or to contract with your consultants to do it for you. Ongoing support from your consultants may include fixing problems that show up only after many hours of use, changes to documentation, or additional training for employees. In addition, ongoing support may include troubleshooting problems, installing upgrades, and system backup. Support can also encompass technical support where your employees can contact your consultants when they need help using the system.

Your custom software application is an investment in your businesses future, and your consultant understands that. A well designed and well written custom software application can help your business remain competitive and moving forward in the business world. Consult Teximus to get started!

The post Installation of Final Software and Ongoing Support appeared first on InTune.

During the beta installation phase, your consultants will come to your site and install the beta software. This part of the custom software project can be motivating because everyone at your business can see how your software application will help you to achieve your business objectives and streamline your processes.

Beta Software Installation.

If the custom application is new, the installation should be fairly straightforward. If the custom application replaces an existing system, you will need to convert from the old system to the new system. You can complete this conversion in one of two ways; you can perform a parallel operation or an immediate replacement operation. During a parallel conversion, you maintain the existing system until the new system is up and running. You have the mostexibility during a parallel conversion as you can use the output from the new system, check it against the output from the existing system, and if necessary, revert to the existing system at any time. Additionally, you can use the old system until all your employees are fully trained on the new system.

Sounds great? Remember that parallel means two. You will be maintaining two systems (for example, entering data twice) if you choose a parallel conversion.

During an immediate replacement conversion, you shut down the old system and start using the new system. While an immediate conversion may be riskier than a parallel conversion, you may need to convert immediately for one or more of the following reasons:

• You may not have the time and resources to run two systems simultaneously.
• The process the system automates may not be so important that it won’t be a disaster if the new system is down for a period of time.
• It may be too expensive to run two systems concurrently.
• The new system may be so different from the old system, that it doesn’t make sense to run both systems in parallel.

Customer Training.

Before you can use the custom application however, you will need to receive some training. Two types of training are needed: training for using the application and training for maintaining the application. In addition, the training that you receive varies depending on the size of the system, the number of people who need to be trained, and whether or not the system is a new system or a replacement for an existing system. The training can take place in many forms including classroom training, one-on-one training, and computer-based training.

How to Get the Most Out of Training

• Make sure you give your employees the time to dedicate exclusively to training. If an employee is distracted by trying to complete training and complete other tasks, the training will not be successful.
• Make sure your employees know how the training will help them so that they will be motivated when attending the training.
• Prepare for the training by reading any preparatory information and by developing a list of questions you want to have answers to by the end of the training.
• Make sure there are enough breaks during the training to keep attention focused.
• Make sure that you not only learn how to use the system, but how to work around errors. Ask the trainer to show you the most common errors that can occur and how to solve them.
• Ask questions. Remember, there is no such thing as a dumb question, only dumb answers.

The user training will be for people who will be operating the application. If the new system replaces a previous manual process, a correlation between each old manual process and each new computer process needs to be established. If the new system replaces an existing system, again a correlation between the new and old processes needs to be documented. If the new system doesn’t replace an existing system, the training needs to include instructions on how to operate the system and how to use the processes that the system automates.

Training will help users see how the new custom application can help your business run more efficiently and therefore remain competitive in the marketplace.

The maintenance training, if necessary, will be for people who will be keeping your custom application up to date. You may choose to have your consultants perform maintenance, and if so, you may not need maintenance training. However, if you will be doing system maintenance yourself, you may be trained in a variety of functions including such things as troubleshooting, installing upgrades, and system backup.

Customer Site Testing and Feedback.

As we discussed in Issue No. 6 of Info Point, site testing is done at your site with your employees using your equipment and your data. There is no simulation during site testing. You and your employees can test the system to make sure the custom application accurately reflects your business processes. Site testing may also uncover additional bugs that had not been discovered previously. Once you have worked with the new application, you can provide additional feedback to your consultants about the system. Changes can be made at this point. However, remember that any change at this point will affect the cost and schedule of the project; the larger the change the larger the impact to both these parameters.

With custom beta software, you get an application that fits your unique needs by automating your existing business processes. Since you are involved in the custom software development project from beginning to end, you can make sure that your custom application will help your business move forward, not hinder it from doing so. And when you need changes, upgrades, and expansions to continue to grow your business, custom software positions you to make these changes when you need them.

Ready to optimize your business with a custom software solution? Consult Teximus today for tailored technology that aligns with your unique objectives and ensures sustained growth.

The post Beta Software: Training, Tests & Feedback appeared first on InTune.

• Hiring a software consultant.
• Ensuring a successful requirements capture process.
• Developing a system specification.
• Making a change to the system specification.

Why invest in custom software? Because your business requirements can’t be met with an off-the-shelf package. When developing a custom software application, the programming phase, when the actual code is created, is probably the most familiar part of a software development project. What specifically happens during this part of the project? Your consultants:

• Use the software and hardware identified during the design phase to develop code.
• Follow the standards, conventions, and style they identified in the system specification.
• Develop a system prototype for your review.
• Create modules that produce the features you need.
• Meet with you throughout this phase to get input into the system.

This method of creating a software application ensures that you have no surprises when your end product is delivered.

Two major components of the programming process are prototypes and modules. A system prototype or pilot system allows you to see the screens, navigation, and features of your system. Each group of related screens that automates a business function is considered a software module.

The System Prototype

The system prototype gives you an opportunity to provide feedback, which your consultants will incorporate as they continue to program. The first demonstration of the prototype might be a series of screens. The screens may not have any functionality behind them, but you and your consultants can review the screens to make sure the features,ow, and design of the screens reflect your business processes accurately.

After you approve a group of screens, the next time you see the system there may be some functionality behind the screens. This programming/feedback process is iterative, allowing you frequent opportunities to make sure the application is effective in addressing your business issues.

Software Modules

The prototype consists of a series of software modules. Each module should be identified during the design phase of the software project and should represent a specific feature or set of related features.

Once the software modules work individually, they must be integrated to make sure they work with each other. The integration begins before all the modules are complete so parts of the system can be tested as the various features are created. This sort of testing allows for discovery of errors early and therefore helps keep costs and schedules in check. As the modules are integrated, your custom software takes shape, and you can anticipate how your software application will help fulfill your business requirements.

Programming with modules guarantees an efficient application in a number of ways.

• Ensures Consistency. A module can be programmed so it can be re-used. This ensures that a feature looks and works the same way throughout the application. There is nothing quite as frustrating as learning how to use a particular feature only to discover that elsewhere in the system, the same feature functions differently. Programming in modules helps avoid this problem.
• Simplifies Training. Re-usable modules can also save on training costs and time. Once an employee learns how to use a particular feature, they can be assured whenever they use that feature in your custom software application, it will work the same way throughout the application.
• Enables Programming Once, Using Twice (or more). If a module can be re-used throughout the system, the module only has to be programmed once. A module used more than once saves on programming time and therefore keeps the cost of the application down.
• Facilitates Change. Modules make changes easier. You may find you need to make a change before the system has been completed. Any change will impact the cost and schedule of a software development project, increasing both. However, if custom software is programmed in modules, the impact may be minimized. If a change affects a single module, that module can be changed without requiring changes to other modules in the system. Or if a change requires addition or removal of a feature, if the feature is described by a single module, the module can be added or removed without affecting the rest of the system.

Three Advantages of Custom Software

Following this iterative, modular approach to custom software development, your final product should be an application that automates your business needs and provides the following advantages:

• You don’t have change the way you do business to fit pre-packaged software.
• As your business grows, you may find you need to make changes to your application to accommodate new customers, products, or business rules. Modular programming simplifies change.
• A custom built, modular system helps your business beexible so it can meet future demands and opportunities.

The programming phase of a software development project can be exciting because you:

• See what your custom software will look like.
• Visualize how the functionality behind each feature matches your business objectives.
• Work with the developers to make sure the system meets your business goals.
• Envision how the application will make your current work processes more efficient.

Custom software can be the key to ensuring your business remains competitive. Contact Teximus to discover the benefits!

The post Programming Phase of a Custom Software Project appeared first on InTune.

A software development project consists of the following phases:

• Requirements capture (Interviews and analysis)
• Design
• Programming
• Testing
• Beta software installation Customer beta testing and feedback
• Final changes
• Installation of final software
• Ongoing support

Your consultant’s goal for the design phase is to develop a specification for a system that will meet your business needs and take into account time, resources, and cost. During this phase, your consultants assemble the information they gathered from you during the requirements capture phase. They identify what you need in a system, how you will use it, who will use it, what system you currently have in place, and how much of the current system you want to keep or change. The consultants will then design the system.

The output of the design phase is the system specification. The system specification is like a set of blueprints that the consultants follow when developing your system. And just as it is very difficult, inefficient, and costly to build a house without blueprints, it is very difficult, inefficient, and costly to build a software system without a system specification.

The majority of the communication you may receive from your consultants during the design phase may be questions to verify aspects of your requirements capture. It is important to make sure the design is carefully created, as aaw in design can lead to aaw in coding, which in turn can lead to aaw in the system.

If you were constructing a building, you might be alarmed to see the roof being constructed before the foundation has been fully designed. In the same way, it would be unwise for the consultant to start coding the screens of a system before the basic structure of the system has been determined. All the modules of a system must tie together seamlessly, and if the screens are designed too early, they might not link well with the rest of the system.

The requirements phase determined what functions you need your software system to perform. The design phase shows how those functions will actually be implemented in the system. Read the system specification very carefully. The design may need to go through several iterations to ensure the system specification describes a final product that will successfully meet your business needs.

Designing Your Computer System

The consultants develop several aspects of your system during the design phase. The consultants:

• determine the overall, high-level design of your system. This part of the design gives an overview of the entire system.
• decide what they will use to create your system, that is, the software and hardware, the standards and conventions they will use on your project, and the style of your system.
• develop a program design. During this part of the design phase, the consultants break down the system into pieces that can be programmed. Breaking down the system into manageable modules also makes changes easier to implement. As we discussed in the previous article sometimes you need to make a change to your specification no matter how successful your requirements capture phase. Small modules allow changes to be implemented more easily. Modules also assist in efficiency and consistency; a well-designed module can be reused in multiple parts of the system saving time and also ensuring that the same feature of a system looks and performs the same way throughout the system. And during this phase of design, the consultants determine how the different modules will interface to present you with a coherent system that is easy to use.
• determine how the new software system will interface with any existing system you may have. During the requirements capture phase, you indicated whether you had an existing system and which features of it you wished to continue to use in the new system. Depending on the project, these features may be retained, but re-programmed, or the new system may interface with the existing system to access the features you wish to retain.
• decide how the system will be tested. The consultants decide on a test methodology and design and develop a test plan.

In addition to designing the actual system, during the design phase, the consultants:

• estimate resources so they can develop a schedule and cost estimate.
• determine whether documentation will be needed for the system and how it will be developed.
• develop plans for system installation and training. The consultants decide on a test methodology and design and develop a test plan.

The design phase should produce a system specification that has addressed each feature identified in the requirements phase and should indicate how that feature will be implemented to ensure maximum ease of use and effectiveness. You should be able to read the system specification and know what you will receive when your software development system is delivered to you.

Need help with the Design Phase of your Software Project? Contact us! We have used our unique business process improvement and software development methodology to design, develop, and implement hundreds of software projects for manufacturing, service, construction, and high technology companies. Call our office in Vancouver today at 778-200-5336 or email us at Info at Teximus to find out more and determine whether we can help with your software project needs.

The post What’s the Design Phase of a Software Development Project? appeared first on InTune.

6. Make resources available.

Your consultant needs access to your current system and your employees. It is only by fully understanding your existing business processes that the consultant can develop a system that fits your unique needs.

7. Include the employees who actually use the system.

You have management goals and know what you need from the system. But, regardless of how great a system is, people will not use a system they don’t like. Include your managers and your internal business experts who work with the current system in meetings with the consultant.

8. Let your employees know their input is important.

If your employees complain that the consultant is focused on technology instead of your business, listen and take action. Your employees will be working with the consultant in a team environment, and they will have a good view of the consultant’s effectiveness. Let employees know that their participation and expertise are critical to the consultant, to you, and to the overall success of the project.

9. Remember why you hired the consultant.

You and your staff know your business. The consultant knows her business. Be very specific and do not take anything for granted when explaining your needs and your business functions. If you don’t understand any aspect of the project, ask questions to ensure your needs are met. Remember that you hired the consultant to help achieve a specific business objective. You’re on the same team, so work together.

10. Take ownership of the project.

Requirements definition is the first – and one of the most critical – stages of the overall project. Your ownership and support of the project during this task sets the tone for the project’s ultimate success. The outcome of your project is ultimately your responsibility.

As shown in the Gause and Weinberg chart, in software development, the earlier you identify a required function, the more cost-effective it is. Adding key functions after the system is 50% complete often means modifying existing code to accommodate the unplanned function, and this can take time and therefore, be expensive.

By following the 5 steps outlined in our June newsletter and the additional 5 steps in this newsletter, you will minimize dreaded scope creep. If coding for a requirement identified early in the process costs $200, the same requirement identified later in the process can easily run into the thousands of dollars. Clear requirements are like accurate blueprints; they greatly improve the probability that the final product will be on time, within budget, and will meet your needs and expectations.

What To Do When You Must Make a Change

With custom software, the scope and features of your software development project may evolve as the project evolves. Even a thorough requirements capture process that identifies every specific function of your new software cannot document all aspects of the way you will work with the system. You may discover that you would like to make a change after the software development project has started.

As a custom software developer, your consultant’s primary focus is on providing you with the features you need so your business functions quickly and efficiently. The specification is the developer’s guide for ensuring the software meets your business needs. However, a good developer will also factor in your feedback throughout the development process as you review prototypes and begin using early versions of the system. Frequently, when you begin to use your new system, you and your consultant discover that what appeared to be a great choice when you were developing the requirements document does not work the way you anticipated.

What else may cause a deviation from the specification? As you see a system develop, you may think of additional advantageous features and functions. Or as a system develops, the consultant may glean additional information from you that allows him to suggest changes that will benefit you and your business.

Are you stuck with exactly what you agreed to in the initial specification and scope of work–and nothing else?

No.

When a feature outside the original scope of the project is requested, then a change order is required. A change order is like a mini-specification, and it defines an addition or change and how it fits into the overall system. The same guidelines that apply to the initial requirements capture apply to change orders.

Here are some considerations to keep in mind when you need to make a change to your system specification.

• Immediately identify any changes as soon as you are aware of them to keep the cost of the changes as low as possible. As shown in the Gause and Weinberg chart, the longer you wait to make a change, the more it will affect the cost.
• A change affects both the schedule and the cost of your software development project. Ask your consultant for feedback on how the change will affect both these parameters.

Here is the procedure for creating and authorizing a change:

• You or your consultant completes the change order form, detailing the change requested. Identify what the change is, what you want to accomplish with the change, and where you think the change fits (which specific screen or menu option).
• The consultant may ask questions to ensure total understanding of a change order if you complete it. After you are comfortable with the consultant’s understanding of the change, the consultant provides you with a signed copy of the change order that identifies how the change will affect the schedule and cost of the project.
• You need to review the change order and decide whether it is worth the cost. If you decide to proceed with the change, you sign the change order and return a signed copy to your consultant.
• If you decide not to implement the change immediately, you still can choose to delay the change to a later release of the software.

Only you can decide if a change is valuable enough to warrant the cost and time it takes to implement the change. The return on investment of the change can dictate whether to make the change now or later.

The purpose of custom software is to provide you with the features you need to automate your business functions without changing them to fit into the pre-determined mold that packaged software requires. Custom software meansexibility–if you need to deviate from the original scope of the software development project, you can do so. Although your consultant should provide you with feedback on the consequences of implementing the change now instead of later, ultimately you must weigh the increase in cost and the change in the schedule against the advantages of the change to decide which is most important for your business.

Unlock Efficient Software Development with InTune! Ensure project success with our proven strategies. From resource availability to employee input, we guide you through a streamlined process.

The post Keys 6-10 to Successful Software Development appeared first on InTune.

Any needs not identified during the requirements capture stage will result in scope creep. According to Suzie DeBusk, President of Teximus, the most effective way to minimize scope creep is to allocate 30% of the time spent on a project to requirements capture, design, and review. How does requirements capture reduce scope creep?

A thorough requirements capture process minimizes false assumptions, therefore reducing the overall cost and length of a project. The International Journal of Technology Management cited that, “companies with intense front-end activities actually spent 40% less time developing their products than companies with few front-end activities.”(1999)

The requirements capture stage is similar to the planning phase of a construction project. If the client and architect do not communicate effectively, the blueprints will not meet the client’s needs. And, depending on the size and scope of the discrepancies, this error in communication can result in costly rework as the project evolves. Suppose a client approves a set of plans for a building, the general contractor breaks ground, and a week later, the client visits the job site and sees that the slab was poured, but the basement was not excavated. The client panics since he requires a basement for storage of critical equipment that needs to be on site. Since his old building had a basement, the client assumed that his new building also would have a basement.

Due to a critical disconnect during the requirements capture stage of the project, a basement now can’t be added without incurring major expenses and significantly delaying the completion date.

Working with a consultant to develop a software system for your business can be much like a construction project. There are, however, some cues to watch for and steps to take to ensure a smooth requirements capture process, resulting in a project that falls within the constraints of time and budget.

1. Be prepared for the initial consultation. Now that you’ve hired someone for software development, don’t lose track of your needs. What are the business goals that prompted you to call in a consultant? Take time to delineate your needs before you meet with your consultant.
2. Remember your current system while creating your wish list. It is tempting to focus on what is missing and overlook the importance of what already works well. Regardless of how basic, do not assume anything. Tell your consultant what aspects of your current system work for you.
3. Communicate. A conscientious software developer will send two consultants to the initial requirements capture meeting. By having an extra set of ears present, the consultants return to their office with a clearer concept of what you need. Ask your consultant to restate your requirements, and keep restating until you clarify any misunderstanding.
4. Look for listening. A good consultant listens. Beware of a consultant who, after 15 minutes, takes over the meeting and tells you that she fully understands your needs. You did not build your company overnight, and your consultant will not understand your needs in 15 minutes.
5. Listen for insightful questions that demonstrate you and your consultant share common goals. You will know how well the consultant has been listening by the type of questions he asks. Is the consultant intuitive enough to know what he doesn’t know and smart enough to ask the right questions?

In our next article, “Requirements Capture: Keys 6-10 for a Successful Software Development Project”, we’ll discuss steps 6 through 10.

Food for Thought

While researching the topic for this issue of the newsletter, I thought about describing a process.

Years ago, I found myself teaching Freshman Composition at the University of New Orleans, where I had an amazing group of students who thought they were excellent communicators. I tried to tell them that I wasn’t a mind reader, but, they continued writing essays that I could not follow or understand. One afternoon, I decided to prove my point. I walked into class with a grocery bag and unpacked all the necessary ingredients to make a tasty peanut butter and jelly sandwich. I told them that I justew in from Mars, where I’d lived all my life and I had no idea how to make a peanut butter and jelly sandwich. So, they laughed and began to tell me what to do.

“First get two slices of bread,” I heard. So, I picked up the bag and tore it open, sending sliced breadying over my students’ heads. Seeing the mess I’d made, they said something about a twisty tie. But, it was too late to fix that problem since the bag was already destroyed. One student, who was starting to get the idea of good communication, carefully told me how to twist off the lid from the jar of peanut butter. She told me to hold the middle of the jar with my left hand while I turned the lid in a counter clockwise motion with my right hand. Finally, one step worked!

Next, I was told to take the knife and spread the peanut butter on the bread. Not knowing any better, I first put the wrong end of the knife into the jar of peanut butter. Then I took the artistic approach and buttered the outside edges of the bread. The students said I had to start over. “But, what about all my hard work thus far?” I argued.

“Sorry, but you should have known what we meant. You don’t put the peanut butter on the edges.” “But, I did exactly what you told me to do,” I retorted.

They screamed in horror when I opened the grape jelly by smashing the jar on theoor. They got exasperated explaining how to clean up the sticky mess. And they became very frustrated when, after I was told to cut the sandwich, I cut it into a dozen tiny pieces. A simple process that should have taken less than two minutes to complete was dragged out to a 25-minute ordeal and was accompanied by much aggravation. Most of the students finally got the message that I could not read their minds.

Consultants can’t read minds either, and they have no way of knowing about your specific requirements unless you tell them. –Rosary Alvarez

The post 10 Tips for Successful Software Development appeared first on InTune.

Consultant: Many of us picture expensive suits and briefcases, lots of talk, and very little action.

Does it have to be that way?

No.

Based on more than forty years of experience in the computer industry, from creating custom reporting software to custom home builder software
here are five proven steps you can follow to be sure your consultant meets your expectations.

I. Understand the Need for a Consultant

Make sure you understand what you want your consultant to do BEFORE you begin interviewing candidates. Ask yourself these questions:

1. What – specifically – is the business need you’re trying to satisfy? For example, I need a way to track the results for each salesperson throughout the month. The process should allow me to create progress reports throughout the month, as well as charts and graphs showing each salesperson’s results and a summary for the company.
2. When do I need it? Be realistic in answering this. You might like to have the solution in place tomorrow; however, you may know that you won’t have the ability to get people trained to use the new system until six months out. Determine a realistic timeline based on your business needs.
3. Do I have an employee with the skills for the job?
4. Is the employee available to complete the job professionally and on time?
5. If the employee does the job, will something else suffer?  If you answer “No” to questions three or four, or “Yes” to question five, you may need a consultant. If so, ask the next two questions.
6. Is the product worth the cost?
7. Is the value of the task greater than the cost of the consultant?

If you answer Yes to questions six and seven, start looking for a qualified consultant.

Virtual CIO Service Packages

Octopus Technologies offers personalized coaching for senior management interested in achieving cost effective solutions through the use of technology. These packages give CEO’s an experienced CIO without adding a permanent employee.

• How CEO’s use the Virtual CIO:
• Straight talk in business terms, not technology jargon, about the pros and cons of technology challenges.
• Participate in senior staff meetings.
• Independent analysis of the cost effectiveness and business value of investments in new computer software or hardware.
• Recommendations on ways to integrate business and technology to maximize productivity.
• Insight into critical shortcomings of established technology solutions.
• Packages vary according to the amount of consultation time you may need. Contact sales@octopustechno.ca for package details.

II. Find a Qualified Consultant

If you are looking for a CPA, lawyer, or building contractor, you can limit your search to licensed professionals. However, in many fields such as computer software development, it is difficult to determine whether a company or individual is qualified to meet your requirements. Ask these questions to help identify the best consultant for your project:

• How long has your company been in business?
• May I see samples of your work?
• May I contact some of your satisfied customers?

If the company or individual can’t answer the questions to your satisfaction, keep looking.

III. Define Your Goals

During the initial interview, provide the consultant with a written statement of the measurable goal(s) to be accomplished. Quantify your expectations using dates, percentages, and other metrics. Being as specific as possible improves the probability that the consultant’s estimate for services will be accurate. It also increases your chance of getting the results you want. Don’t assume that because the consultant is an “expert,” she can tell you what you need. Some consultants have a “canned” solution they attempt to apply to every situation. Beware of a consultant who arrives with a solution in hand!

The consultant should do more listening than talking in the initial interview. You want a consultant who will understand your business and apply her expertise to achieving your business goals. Keep looking if the consultant’s approach is to shape your business into a package that is familiar to her, which makes it easy to apply previous solutions to your unique opportunities.

IV. Clearly Define Roles

Bringing in an outsider is a big change for many companies, and it may make your current staff anxious. To maximize cooperation between your staff and the consultant, while minimizing the anxiety associated with the fear of change, tell your staff why you hired the consultant. Explain the project plans and goals, and communicate with your staff regarding any impact the consultant’s work may have on their positions.

Consider using the following techniques to make the consultant a part of your team:

• Team trusted staff members with the consultant for the life of the project.
• Take the consultant and members of your staff to a working lunch.
• Have members of your staff involved in status meetings with the consultant.

These steps reduce staff anxiety and improve the productivity of your software consultant.

V. Use Milestones to Track the Project

Don’t wait until the end to check the consultant’s progress. Establish measurable, concrete intermediate deliverables to allow you to monitor and measure ongoing progress.

For example, in a software project, the initial deliverable should be a clear scope of work, and this may take one to two weeks, depending on the size of the project. The next deliverable may be a set of prototype screens, which may require an additional two to three weeks.

Interim deliverables allow you to quickly determine whether your consultant is on track for completing your project on time and within budget.

Conclusion

Use these five steps to ensure that your software consultant delivers what you need to meet your business objectives. This creates a win-win – you get what you pay for, and your consultant gets another satisfied customer.

Ready to embark on your custom software journey? Contact us for expert guidance and a solution crafted to meet your specific needs.

The post 5 Ways to Get the Most Out of Your Consultant appeared first on InTune.