Your software project was estimated to require 10,000 hours, but after 10,000 hours of work, only 50% of the functionality is complete, and the project has already exceeded the original budget.

Your CFO is yelling, “This has to stop!”

Your COO says, “We have to get this new functionality in place.”

Here are five questions to help you decide whether to pull the plug on the project or keep going.

1.Does the software work so far?

If your project manager is telling you that the system is 50% finished, but you’re still waiting for the first opportunity to test the system, stop the project now.With the tools available today, you should have the ability to test the first screen or module of your new system shortly after the design phase is complete. If it’s late in the project and you still haven’t had the opportunity to test working code, there’s a very low chance that you’ll end up with a working system at the end.

2. Will the finished software address the business goal?

Based on what you’ve seen so far, will the finished product work as planned to solve the business problem? If the software is late, can you still take advantage of the business opportunity as planned? If not, cancel the project now. If the product doesn’t look like it’s going to meet your needs when it’s 50% complete, it’s not likely to meet your needs at 100%.

3. Are there good reasons for the project to exceed planned time and cost?

Did requirements change? Were new requirements added? If so, it’s reasonable to change the original time and cost estimate. If the requirements didn’t change, did your software project manager explain the time and cost overruns and provide you with an updated estimate of the time and cost to complete? Can the additional time and cost be justified? If so, consider continuing the project.

4. Can the team deliver a sound final product?

Software – even software packages with 1000’s of users – always has bugs. When you find bugs, are they tracked and fixed? Are you able to test the corrected code in a reasonable time? If what you’ve tested so far works reliably after the developers fix your bugs, it’s likely that the final product will work reliably, too.

5. What does your gut tell you to do?

Do you trust the project manager and the team to deliver? Do you feel optimistic about the final outcome of the project? Something inside is telling you whether to proceed or stop, and you need to factor that into your decision. It’s not easy to decide whether to pull the plug on a project into which you’ve invested time and money. If you answered NO to question 1 or 2, you have tangible reasons to stop your project now, but if you answered YES to questions 1 through 4, you’re going to have to rely on question 5 – and input from trusted peers and those involved in the project – to make a decision.

Ultimately your software should be a valuable corporate asset that helps you achieve your business objectives. Anything less isn’t worth your investment.

Hi, I’m Suzie DeBusk, CEO and Founder of Dragonpoint – we are specialists in driving improvements to your business’ operations through the use of process changes supported by some awesome technology solutions. Today I’m going to take a few minutes to talk to you about How to Climb Out of the 3 Most Common Business Process Pitfalls. In this economy, businesses want to save money without compromising product or service quality. One way to achieve this it to optimize performance by improving business processes.

Based on facilitating more than 50 process improvement projects, we’ve compiled the following list of the three most common pitfalls resulting in inefficient processes.  And we also share our secrets for figuring out how business can grab a ladder and climb out of that pit.

Pitfall One:  We’ve always done it this way

I can’t tell you how many times in my career I’ve heard this answer.

Get out of the pit:  Ask why, who, and where questions to figure out what needs to change (and then change it!).  Sometimes easier said than done. Performing tasks in a consistent, reliable manner is critical to a successful business.  How can you find out whether consistent reliability has become the enemy of efficiency? Ask Why, Who, and Where questions that uncover important areas for improvements. Questions like:

Why do you create that report every day? Sometimes people don’t even know why they are doing it.  Some lone gone manager from 10 years ago asked for it on three consecutive Mondays so it got added to a “to-do” list and never questioned.

Who gets that report?  We once had a young woman who received a weekly report that she literally threw in a pile and never looked at. That went on for several years until we started asking why she got it.  Turns out there was helpful information on it, but she’d never bothered to look.

• Why do you enter information only on Fridays?  Believe it or not, this sometimes happens.
• Why is this always the first thing you do? Once again, no one questions.
• Where are they when they need to see the results?

Don’t assume anything.  Ask the person responsible for the work why, who, and where questions for every task, and when the answer is “because that’s always how we’ve done it,” probe deeper.  What worked last week may be irrelevant this week.

Pitfall Two:  Silos (Local Optimization)

Get out of the pit:  Let people know what happens upstream and downstream. Most people want to do the best job possible. But lack of visibility into other departments creates localized efficiency at the expense of before and after processes. One of the most rewarding parts of an improvement project is watching people get excited about their ability to add value elsewhere in the process. When we get everybody into one room to walk through the business process together, we celebrate when we hear people say things like, “That’s what you do with the information I enter?  I can save you time by taking 30 extra seconds to enter one more thing!”

Pitfall Three:  Stealth Systems

Get out of the pit:  Figure out what’s missing and fix the primary systems. People do their job to the best of their ability using the tools you give them, and when they find that a company’s business information systems are missing something, they don’t yell about the hole – they fill it. How?  They go under, over, or around the big integrated system and create a stealth systems – using either Excel or Access created to handle things that aren’t covered by the main system. The list of potential problems with these systems is practically endless:

Key business data is added or modified outside the business rules that control your primary application.

• Few people know the data exists and how to use it.
• The data may not be backed up because it’s not part of the standard backup routine.
• Reports based on the primary system data may differ from those created from the stealth system.

Are you too busy to do your daily job and focus on process improvement, too?

If you’d like to know more about process improvement, check out our newsletters on our website:  http://www.dragonpoint.com especially the article called Getting Healthy in 2011. But you know, If you’re busy 10 hours per day already and don’t have the time or training to conduct your company’s process improvement project, call DragonPoint at 321-631-0657.  We can help.

Thanks for spending this time with us today!  This is Suzie DeBusk.

7 ways to avoid system failure

We talked earlier about how hiring your brother (sister, cousin, nephew, friend . . . ) who is learning to program or relying on one person for support are ways to guarantee system failure.

Here are 7 specific recommendations to ensure you don’t get stuck frantically searching for a programmer to get you out of a crisis with your production software.

1. Hire a qualified developer: Ask questions and check references to be sure the person has the qualifications you need. When fighting for a job, people can be careless with their handling of the truth.
2. Hire more than one developer: Instead of hiring one programmer, hire two. If you can afford to hire only one person, invest in an external consultant who will become familiar with your code by working with your employee on specific tasks.
3. Contract with an experienced services firm: If you hire a software development firm, be sure the company has qualified developers who’ll work on your project. Also confirm that they cross-train and/or will assign more than one person to each of your projects.
4. Control the source: Even if you have only one developer, use a source control tool to manage changes to your system.
5. Keep your versions organized: Keep a set of code for the production version of your system separate from the source code that is being changed to address new and modified business requirements.
6. Keep your working version clean: Have your team “build” each time changes are checked into source control. A build compiles all the code and flags programs that are incomplete, so your working version will actually work.
7. Manage tasks: Even if you can’t afford the sophisticated tools big companies use to associate business requirements with code changes, you can create a spreadsheet to track tasks. Start with your planned tasks, and have developers update the list at least weekly, though daily is better, to show status (planned, completed, and in process).

Follow the guidelines above and create an environment where you’ll always have someone who’s qualified to update a very important business asset – your software.

Are you trying to guarantee system failure? (part 2)

We talked earlier about how hiring your brother (sister, cousin, nephew, friend . . . ) who is learning to program is a way to guarantee system failure. Sadly, it’s not the only way. Another recurring problem is relying on one person for support.

Whether it’s an internal or external resource (and especially if it’s your brother/sister/cousin), you’re taking a big risk when you have only one person who understands and supports your business software.

In one real-life example, a company that sells a software package came to us in a panic because the contract programmer, who was the ONLY programmer who had ever worked on their code, had suffered a heart attack and died. The developer’s estate provided the source code to the company, but they had no idea what to do with it.

We restored everything, but it was impossible to identify the production source code or database among the many versions, because the programmer didn’t use source or version control. The code with the most current date wouldn’t compile, so we assumed there were changes in process, though there was no documentation or task list to support this. We finally pieced together a solution, but resolving production issues continues to require significant digging through poorly structured code.

Big companies with multi-person development teams can run into the same problem if they allow one programmer to become the sole expert for an application.

Remember the old saying about not putting all your eggs in one basket? This definitely applies to software development.

Are you trying to guarantee system failure?

When selecting software and support, some bad decisions transcend company size and industry. One of the worst things you can do is to hire your brother (sister, cousin, nephew, friend . . . ) who is learning to program.

It seems like a great deal at the time. Your best friend loves her programming classes, and when she hears you complain about how hard it is to find a good software developer to make a small change to your application, she offers to do it at a very low rate after hours. You agree – thinking, “What can I lose?”

Turns out you can lose both your friendship AND the reliability of your software.

A new programmer needs to work under the direction of an experienced software analyst. No matter how great the teacher and how applicable the classroom experience, it’s not the same as working on a real production system.

One out of 20 people who are learning to program can complete the work you need in a timely manner, but do you really want to bet your software on a 5% chance of success?

Experience and teamwork are necessary to successfully modify existing software or integrate applications. Designing and developing a new business system requires skills that are almost always beyond anything students learn in a classroom situation.

We’ve completed the code for many systems that were started by an inexperienced developer who got to what he or she thought was “90%” finished. In the best cases, 50% of the functionality was coded, and the original design and most of the existing code could be salvaged. In the worst cases, we had to start over.

If you really want to hire a relative or friend who is learning to be a programmer, do both of you a favor and be sure to pair him or her with an experienced IT professional who can mentor and supervise.