Babson Consulting, Inc.

The Biggest Challenge is Implementation
How do you get it created? As you know, the biggest challenge in business is not the idea, it’s implementation. There’s no innovation without implementation. When you’re successful, you achieve competitive advantage. Remember Bob? First to market with competitive power?

Because We Have Been Doing It Wrong
Here is how not to create your solution, get a team of 20 or 30 IT people. That is a proven path to incredible waste and failure. Just like Henry Ford’s people prior to the assembly line, our poor IT people are forced to use a process of extreme inefficiency and disastrous quality.

But My 10 Principles Change That
Instead, I use 10 development principles that deliver a tenfold increase in efficiency and unprecedented quality. I won’t go into all 10. It would make this text too long. They’re all explained in my book, beginning in chapter 5 page 71.

Together, we’ll walk through a few of the most important concepts.

Team Size – How Many People for the Development Team?
The first concept is team size. Remember, it may be a large solution, but it’s not a large project. That was true with my first rubber room project in 1970. 37 years later, it’s still true

Small is Beautiful for Corporate Software Projects
Large teams are great, for digging a tunnel. The more shovels the better. For corporate software, where communication is critical, too many people dramatically slow the project.

A team of eight has 28 lines of communication; a team of 120 has an astounding 7,140, the project is 255 times more complex! Even worse, more people means an increasing number of errors.

Don’t Just Take My Word
Since 1978, Quantitative Software Management (QSM) has led the IT industry in software metrics analysis. In 2005, they used metrics from 7,000 projects to analyze productivity and error rates:

A 2-person team creates 40,000 lines of code in 600 days
Adding 27 more people, buys you 12 days
And six times as many errors

In another study of 564 projects completed since 2002.

34 people completed 100,000 lines of code and cost $2.1 million
Cut the 34 down to 4 and it takes just two weeks longer with a cost savings of $1.84.

Don’t just believe me, books; articles, papers and studies published for decades, all come to the same conclusion.

Limit Your Risk Now
It does seem logical. Large software projects require a large team. It’s absolutely not the case. Small is beautiful for software development teams. In fact, if you have an IT project that has more than eight people or is planned to take more than a year, cancel it. Odds are very high it will fail.

Team Membership – Who Should Be on the Team?
If you’re wondering, who needs to be on the development team? There are five responsibilities, and you will be surprised only two have anything to do with IT.

A business representative, with deep knowledge of your business who
can speak for you
A documenter to continue your story, in prose, no technical jargon, a journalist, who can finish the story
A tester, someone from your business area with deep knowledge of your old legacy software
And finally, two IT responsibilities
- A Team leader with broad business experience and extensive software development experience
- A programmer, you can have as many as four of these

Remember This
Now, this is important. Never exceed the maximum of eight and don’t cut corners with quality and experience. It’s false economy to get only smart, 22-year-olds. You need some grey hair.

What Tools Should the Programmers Use?
We’ve already discussed the rapid prototyping process where you, your senior management and the development team continue the design. But how do you pick the tools programmers use to create the prototypes? I use the CEO’s method. Pick the one that gets you to done the quickest.

There is Only One Criterion
Don’t choose what everyone else uses, or whatever Microsoft is selling or even what your IT guys want. There is only one criterion: the largest amount of software created in the shortest amount of time. Period.

With software for 1/10 normal cost, standards don’t matter. Maintenance is history, when it’s obsolete, throw it away, create new software. The 80% of your IT budget you spend on maintenance goes right to the bottom line.

Traditional Tools Just Add to the Problem
Traditional tools like Java, Visual Basic, C++ are horrendous choices. They require translating business requirements into some logical procedure or structuring the requirements into some form of object methodology or modelling language or creating use cases, or a lot of other buzzwords that all add up to a lot of expense for zero business benefit. It’s tedious, labour intensive, error prone and requires pre-existing detailed specifications. We’re back in the construction business. We want to stay in the decorating business.

RAD is the Only Choice
Rapid application development (RAD) tools are the only option to quickly create a working prototype and demonstrate it live, so you can “see” what you’re getting.

Spreadsheets miraculously simplify the creation and display of even the most-complex numerical problems. RAD performs the same miracle for business software.

It’s a powerful concept. And when the prototype is complete the solution is complete. The traditional systems-development cycle is totally avoided, a tremendous boost in productivity.

What RAD Platform Should You Use?
What specific RAD tool should you use? I am glad you asked that question. There’s one choice. eDeveloper from Magic Software Enterprises. It is so superior; I wouldn’t consider anything else. It’s the perfect balance between spreadsheet like speed and programming power.

The Awsome Power of eDeveloper
Just to give you an idea of its awesome power: An international software developers’ competition, sponsored by Droege Computing, was held annually for several years in Durham, North Carolina. Over 200 independent software developers from around the world competed for cash and prizes.

The contest was to create a real-world application in 14 hours or less using specs provided at the start. They could use any development tool they wanted.

They Could Never Unseat eDeveloper
Contestants using eDeveloper won the competition five years in a row. In the final year, teams using eDeveloper, came in 1st, 2nd, 3rd, 4th and 5th. The competition was cancelled, people using other tools were no longer willing to compete. The rules changed every year at the request of competing tool vendors, but they could never come up with a way to unseat eDeveloper.

I just have one comment; why on earth would you ever use anything else.