Author: Cary Toor

Need A Sales Person: Simple Math to Figure It Out

Posted on by Cary Toor

Posted By Cary Toor

Most businesses want – and need – one or more Sales People.  This discussion takes a simple look at the math behind direct sales people for a subscription or recurring revenue model business. 

First, let’s get the definitions out of the way first.  A Sales Person is an individual who is contacting other individuals and/or businesses directly through email or phone to actually sell (including finalizing the sales) of a product or service. 

Let’s take a hypothetical Sales Person.  Assume that the Sales Person costs $50,000 per year.  If the Sales Person is an employee (as opposed to a contractor), the salary needs to be multiplied by a factor of 1.2 to get the actual cost – which includes taxes, 401K, insurance, and other benefits – which gets you to $60,000 per year.  Under this analysis, our hypothetical Sales Person would cost $5,000 per month or $1,155 per week. 

Assume an average price for your Company’s services of $1,000 per month per customer every month (reoccurring) to make the math easy.  If you have a gross profit – profit after all direct costs of the service are deducted, but not including overhead costs such as rent or administrative salaries – of 35%, the profitability of the service is $350/month. 

If you are going to roughly break even on our hypothetical $50,000 per year Sales Person, he or she must sell roughly 15 customers per month.  That would generate $5,250 in sales.  However, since you are generating reoccurring revenue every month, your sales person does not need to break even in a month.  In fact, it doesn’t even make sense to have your Sales Person break even in a month. 

So, one of your most important decisions you will need to make is how fast you want your Sales Person to break even.  You need to be realistic.  How many sales can you reasonably expect your Sales Person to make each month?  Most companies I have worked with use a benchmark of 4-6 months.  That would mean your hypothetical Sales Person would need to generate 4 sales per month or $1,400 in gross profit if you use a 4-month breakeven or 3 sales per month or $1,050 in gross profit if you use a 6-month breakeven.  The bigger the gross profit percentage, the longer you can use for breakeven. 

If you can’t break even on you Sales Person in 6-9 months, you need to consider one of the following:

  • You are paying your Sales Person too much.
  • Your monthly fees to your Customers are too low.
  • You need another way to sell besides a Sales Person/Direct Sales model.

Not all services or products can be sold direct by a Sales Person.  Low price, high volume services or services which generate a very slim gross profit are better sold through digital marketing. 

If you plan to use commission in addition to salary to compensate your Sales Person, you might set your quota at the breakeven point (or a little above the breakeven point) and pay commission on anything sold above the breakeven point.  So, in our hypothetical model above, if your breakeven point is 4 months, the quota would be 4 sales per month and commission would then be paid on the additional sales (using the gross profit, not the sales price).

Of course, you still need to hire an effective sales person who can meet or exceed your expectations for the number of sales per month.  Also, remember that the first month or two may not be productive since it takes time for a new Sales Person to find his or her footing.  Over time, however, the number of sales for a productive Sales Person in a set period should increase, which is one of the marks of an effective Sales Person. 

I realize that this is a fairly simplistic way to look at sales costs vs. revenue.  However, it is a good benchmark to allow you to figure out whether or not you can afford to use direct sales resources and what you can afford to pay.  I have attached a copy of my model if you want to modify it for your situation and use it.   

Is it Done Yet? A Recurring Lesson in Software Development Management

Posted on by Cary Toor

By Cary Toor

For all software development projects, we start with a project plan divided into milestones and tasks.  To get the project done, we need to know the status of each task and mark the task as done when it is completed.  Is it done yet?  Can I mark it as complete?  These are the critical questions in project management.

In the days when I managed or oversaw projects, I felt like a broken record because I asked this question all the time (and everyone in my organization was tired of hearing it).   I am sure that everyone who has managed software development projects feels the same way (at least most of the time). 

You would think that this would be an easy question to answer (since it is a simple yes or no answer).  Unfortunately, this simple question is where project schedules and budgets tend to fall apart. 

In this short discussion, I will attempt to provide some tools and techniques to get an accurate answer to the question, “Is it done yet?”

First, what does done (or 100% complete) mean?  It means that the coding task is done, that the developer unit tested the task, and, hopefully, that a tester has followed up with his or her own unit testing and signed off that the task meets the requirements.  It does not mean that the coding is done and testing is pending or that testing is in progress.  Done means done!

Now, let’s look at how this works into a real project.  Project plans (schedules and budgets) are creating by devolving the project functionality or if you are using Agile, the functionality assigned to the construction iteration, into a series of subsystems, modules, and coding tasks; progressively smaller chunks of work that are finite and easy to understand.  If we strive to make the coding tasks small with clearly defined functionality (say no more than two-to-four days of effort), it is not difficult for an experienced developer or analyst to quickly build a working project plan with reasonable effort estimates.  Unfortunately, every Project Manager knows that good project plans only stay on track a small percentage of the time (which is why getting a project done on schedule and budget seems to be an elusive goal). 

So why is this?  Let’s assume that your requirements are correct (a very large assumption) and talk only about the coding or construction phase.   So, is the task done?  A strong, experienced developer who has unit tested his code says “yes.”  What could possibly go wrong …

  • the code could blow up when certain functionality is exercised.
  • the code could have subtle logic errors.
  • the code may not integrate correctly code written by other developers.
  • the data model may have been changed.
  • the code may work in the development environment but not in the production environment.
  • …and so on.

As I indicated above, assuming that you have experience with software development, in theory it is easy to estimate how long a small, well defined coding task should take.  What is impossible to estimate is how many iterations of testing, followed by bug fixing, followed by retesting will be required for any given piece of code.  This can be dependent upon …

  • the individual developer assigned to the task.
  • the quality of the tester assigned to the task.
  • the quality of the development environment.
  • …and so on.

Compounding this, the longer it takes to uncover the problem, the longer it takes to get that problem resolved.  If the problem is uncovered during initial development or immediately thereafter, the developer can usually correct it quickly.  If the problem is not uncovered until later, the developer has moved on and is working another task.  That means (a) the developer has to stop working on the task he or she is working on, pick up the prior task, attempt to figure out what he or she did previously, and resolve the issue, or (b) the testing has to stop and wait until the developer is done with his current task.  For obvious reasons, both of these are bad options with an impact on the project budget and schedule.   A few tasks with simple fixes might not create any scheduling impact (because of course we all pad our schedules).  Multiple this by 50 or 100 tasks and the schedule goes downhill quickly.  Option (b) is probably the best option.  Early in the project, the tester can move onto other sections of the project, although this is how tasks get marked 80% or 90% and never get completed.  Option (a) is the only option as the project proceeds into its later stages to make sure tasks actually gets to 100% complete.

So, what can you do about this?  Of course you could pad every coding task in the schedule by 50% – 100% or you could greatly increase the time and resources scheduled for testing.  Whether you can get away with this depends on how flexible (read malleable or lack of concern) your customer and other stakeholders are about the project schedule and budget.  Alternatively, here are some strategies you might use to reduce this problem …

  • When you are creating the project plan –
    • Make sure the tasks are small enough to accurately estimate (such as a single simple Web Page, Tab on a Page, or Stored Procedure).  It gets very difficult to close out a task if it requires more than 1-2 days of coding effort.  Also, remember that it is easier to code and test a single, simple piece of functionality that a complex piece of functionality by a factor of many times.  (This is why tasks should be small!)
    • If you are using code-driven unit test tools or frameworks, schedule in ample time to write the unit tests for each task so they are robust and likely to identify reasonable coding errors.
    • Move up the initial integration testing of each major component of code (i.e. anything that can be tested stand-alone) so that it is done immediately after all coding tasks are complete.  Do not defer integration testing until all coding is complete.
  • Overall during the development / testing tasks –
    • Have a tester unit test the code independently (or view the developers unit testing) immediately after the coding is complete. 
    • Have the developer fix any problems identified before they move on with the next task (where possible).
  • On the developer side –
    • Developers do not like to do thorough unit testing.  Make sure your developer is actually doing the unit testing (and not handing off buggy code). 
    • For each developer, track the iterations required to close each module (this functionality should be available in any reasonably robust problem management tool).  It turns out that developers are pretty consistent; either high or low.  There is no grey area.  If the iterations are consistently high and you point this out, it can get substantially better.
    • Have the developer sit with the tester at least some of the time or involve the developer in group testing activities in which the whole team comes together to do testing of the entire project.

Developers usually have a style; (a) slower coding, lower bug counts, (b) faster coding (30%-40% faster), higher bug counts.  One of my Project Managers was always stressing to me that the slower coding, lower bug count developers are better (or at least more predictable)!

In any case, done needs to mean DONE.  It can’t mean half done, 90% done, or done without independent verification.  Projects are not completed when 100% of the task are 90% done.  Projects are only complete when 100% of the tasks are 100% done.  I know this is obvious, but I have seen many projects where 50% of the tasks were marked 70%-90% done and the stakeholders are screaming about the budget and schedule getting broken.  The bottom line… Don’t mark a task as done until you have some independent confirmation that it is done!

 

 

 

 

Improving the Likelihood of a Successful Startup

Posted on by Cary Toor

Posted By Cary Toor

It is a truism that  a very large percentage of start-ups never progress past the early stages, in which founders use their own money and money from friends and family to build a product and try to take it to market.  The Small Business Administration estimates that about half of all startups fail within 24 months.   A total of 70% never become viable, on-going businesses.  I would like to examine why and provide some strategies to increase the probability of success.

Over the past few years, I have worked very closely with a half-dozen early stage start-ups and have been involved in another dozen as an investor, mentor, or consultant.  All of these ventures are focused on using innovative software to disrupt the industries they are targeting.  I define early stage as having a basic product (Minimum Viable Product) and raising money from friends and family but little or no outside capital, which is the type of company I am discussing here. 

I-Corps, the National Science Foundation’s Innovation Project designed to help start-up businesses, believes that the reason many small businesses fail is that they build products no one wants.  I don’t really believe this is the case (although it can be a contributing factor) since this is easily remedied by reaching out to the community of potential customers and users to first discussions their interest and willingness to pay and subsequently show them early product demos and obtain and incorporate their feedback. 

Need to Pivot from Internal Focus to External Focus

Based on my experience, I would argue that the primary reason these startups fail is that they cannot make the pivot from being internally focused to being externally focused.  What I mean by this is that in the very early stages of a startup, founders need to be internally focused: building the product, getting financing from people they know, and working closely with a small group of substantive experts to test the product and get it ready for the market.  Once they have a viable product that customers might be willing to pay for, the founders need to pivot so they are externally focused: switching their focus from product development to customers and activities including marketing and sales, improving their products by incorporating customer feedback, and getting in front of new potential customers and investors. 

From my experience, one of the major reasons why startups fail is because their founders cannot make this pivot – which is admittedly is very difficult.  In many cases, this means that founders have to engage in activities they are not comfortable with or experienced in including: cold calling potential customers and investors, getting rid of staff involved in product development to free limited resources for marketing and sales, and internalizing and fixing negative feedback on their product.

Most founders come out of the industries they are attempting to disrupt as substantive experts in their industry.  Many are more comfortable with product development than marketing, sales and customer outreach. 

Many founders want to continue to direct limited resources into product development and not start selling the product as soon as possible.  A common refrain is “we only get one chance to get the product right and can’t bring it to market until then.”  Although it is important to get a working product with no bugs, it is essential to begin to generate both revenue and customer feedback through sales and customer usage.  For that reason, a minimum salable product should be the initial goal, with features added after the product introduction.  In fact, no one gets it right the first time and getting it right means incorporating feedback from customers.  Product development is an evolutionary, never ending process.  Money needs to be redirected toward marketing and sales as quickly as possible, however, product development can never stop.

One of the keys to success is to begin to generate revenue as quickly as possible.  This means (1) as founders talk to their community of potential customers and users, continually ask them whether or not the product as it currently exists is enough to begin to solve their problem (along with promises of future features) and will they begin to use it, and (2) give significant discounts for early adopters to speed up the feedback loop. 

Increasing the Probability of Success

This problem can be mitigated if one of the members of the founding team is responsible for marketing and/or sales.  Alternatively, while talking to the customer community, it may be possible to find a sales champion who can be added to the team gradually, first as a mentor, then part time, then finally full time when a product is ready for customers. 

In any case, the pivot from internally focused to externally focused has got to be gradual, it cannot be a hard cut.  From a tactical perspective, there are a few of strategies I have suggest, which definitely help:

  • Ensure that Founders commit to spending at least 2 days per week (or 4 half days) talking to potential customers and investors during the product development stage, starting on day one!  You would be surprised have few founders actually do this since building the product is typically why they start the business in the first place. 

 

  • Develop a list of every potential customer and investor the start-up gets has contact with and send them a short, blog-type email each month talking about the company, the product, and the current status.  This keeps everyone warm and I really believe shortens the sales cycle for both product and investment when the time comes.

 

  • Put together a small group or community of customers who are likely to be early adopters of the product and obtain their feedback on a regular basis. This group can also be used to answer questions about necessary product capabilities and features.

 

  • Even before the product is build, develop literature (web site, white papers, etc.) on the products planned capabilities and features.  Use this to get the founders selling.   Have the founders get non-binding letters of intent from potential customers before the product is completed.  This helps (1) identify customer objections to purchasing the product early and (2) improves the case – and valuation – for investment.

 

  • Structure product development so you have a demo or working prototype as early as possible (even if this lengthens the development cycle).  Once there is a demo or prototype, the founders will typically feel more comfortable getting out to sell to customers and investors. 

 

  • Structure conversations with customers and investors in a way that allows founders to express their passion.  This makes sales calls easier!

In addition to making the pivot from internally focused to externally focused, these strategies serve to validate the product and give confidence to investors, which will ultimately provide a better valuation and generally increase the likelihood of success. 

 

Building Your Software Product: A Primer for Entrepreneurs (Part I – Strategies and Tactics)

Posted on by Cary Toor

Posted by Cary Toor

 

Most start-ups need to develop software.  I have worked with many Entrepreneurs who are building software to get their companies off the ground, including web apps, phone apps, and programs using natural language processing and artificial intelligence.   Some of these Entrepreneurs come out of the software industry.  Others are building software for the first time.  Virtually all of them have one thing in common: they struggle to get the software into their customers’ hands.

Every start-up I have worked with has been short on both money and time.  Delays and cost overruns can cause unbelievable stress and even end a venture before it has a chance to get to market.  Unfortunately, in the software development world, delays and cost overruns are normal, even expected.  According to the Standish Group’s 2015 Chaos Report which examines the success of software projects, less than one-third of all projects done by sophisticated IT organizations were deemed fully successful.  About one-fifth were total write-offs, with the remainder lacking significant functionality when time and money ran out.  Very few start-ups fall into the category of sophisticated IT organizations, which reduces their chances for a successful project.

Since I work with start-ups every day, I have tried to come up with a very brief primer to improve the chance that Entrepreneurs will succeed in their software development projects by identifying a few simple strategies and techniques which have been shown over time to dramatically increase the chance of project success.  If you are experienced in software development, many of these strategies and techniques will be familiar to you.  However, they bear repeating in this context since, many times, experienced developers run into just as much difficulty (although maybe of a different type) that novices.

 

Software is Evolutionary

One of the primary reasons software is difficult to build is that it is difficult to define what needs to be built (referred to as requirements).  Even if you know what you want, it is difficult to get it right the first time.  Getting it right means a lot of different things:

  • The software performs the functions you want.
  • The software operates smoothly, without errors or problems.
  • Your customers like the software enough to use it and can actually figure out how to use it, in most cases without instruction (or don’t simply reject it).

Typically, an Entrepreneur starts with a plan in his or her mind to build software that encompasses all of the functions he or she can think of.  If the business successfully implements all of these functions and gets the software in front of customers in their first iteration, they quickly find that many, if not all, items need to be redesigned, reworked, or otherwise revised.  I would argue that this situation is significantly worse for start-ups than for established companies because start-ups have unique idea where established companies are typically upgrading or reengineering an existing process or adding functionality to an existing business.  Established companies also have typically have stronger knowledge of and relationships with their customers than early-stage start-ups.

The National Science Foundation (NSF) teaches a methodology for start-ups called I-Corps (for Innovation Corps) that focuses on a couple of major areas that are pertinent to this problem:

  • Make sure you know your customer and what your customer wants.
  • Initially go to market with the minimum viable product.

I-Corps training focuses on getting the Entrepreneur to meet with a large group of potential customers to vet their product idea and functionality.  This has the advantage of making sure that the start-up will (1) better define the product, (2) validate the market for the product before it is built, and (3) work through the required functionality with potential customers.

The NSF methodology then calls for the development of a Minimum Viable Product (MVP).  This product needs to be simple and have the minimum number of functions and features necessary to implement the business solution; with all unnecessary functions and all bells and whistles removed.  If you have talked to customers, you can do this by making a list of functions and features and marking them as (1) Must Have, (2) Nice To Have, and (3) Optional.  Only implement the Must Haves on the first go around.  Turn this list into a project plan that will allow you to assess and measure your progress.

This strategy will greatly simplify development, reduce development time, and lower cost.  If the functionality is simple, it is also less likely that significant rework will be required, although enhancements and features will need to be added.  Limited product testing with customers will tell you what needs to change or be added before releasing the product to the marketplace (see below).   Remember, it is much less risky, much less expensive, and much faster to make enhancements to a base product than to have to do major rewrites before you can release the product. 

I constantly hear the following reframe from Entrepreneurs I work with: “We only have one chance to get it right.”  I would argue that you only have one chance to get your product to market.  It needs to be bug free and easy to use, but you are better off trying to start with the minimum product and then add functionality and features based on customer feedback.  That is evolution, a strategy which was used successfully by all of the successful technology companies I can think of including Google, Amazon, and virtually everyone else who has a successful software-based product!

 

A Few Word About User Interface Design

Everyone is very concerned with User Interface (UX) Design. The minimum viable product strategy goes for UX design as well.  Implement the basic UX features and eliminate as many bells and whistles as possible for the initial release.  It is better to have a consistent, easy to use UX pattern than to completely minimize keystrokes.   

Most importantly, before you start coding, make sure the UX is easy to code!  I have seen many UX Designs that look great, but are very difficult and time consuming to code and test.

Many times, we use a UX design based around a summary – detail model in which summary information is displayed and then edited or added on detail screens.  Although this strategy does not produce the optimum UX, it does have the advantage of being (1) easy to code and test, and (2) easy for users to learn.  Make sure you mock up the UX before you move into coding so the developers know what they are supposed to build, and, it goes without saying that you need to make sure the developers build what is actually contained in the mock up (more on this below).

 

Changes Kill Projects

One of the reasons why software project are always behind schedule is changes that occur during coding, to either the application functionality, operation, or user interface (or all three).  Circumstances will definitely force changes during development and the longer your development takes the more changes will be required.  Although I understand that it is necessary to make changes during development, you need to keep them to a minimum. Unless the changes are critical, don’t make them until after the first release.  The more changes you make, the more bugs will be created and the more time you will spend getting the software into production.

Here are some strategies to keep changes during development to a minimum:

  • Document all of the functions you will be implementing, what they are supposed to do and how they will work.  An easy way to document is to start at the function level and then list all of the features inside the function. (Functions are high level and features are capabilities inside a function.)

                   Feature 1                Detailed description

                                      Function 1     Description

                                     Function 2     Description

                                                  …

I realize that this is time consuming and requires a lot of discipline, but it is substantially less time consuming that making changes during development.  Also, it will force you to think through what you want to build, and it will make it easy for other people to get involved in the testing process. 

  • Write down the business rules and work flows that are needed in detail so you can give it to a developer to work with. 
  • If you have a user interface, mock it up before development starts.  Use a Visualization Tool that allows you to paint fields onto screens and link screens together (like I-Rise, JustInMind, or Axure), or just do the mock-ups in Microsoft Access.  Don’t deviate from the mock-up.

Turn this into a project plan that you can track!

As you make changes, preferably change the documentation and the visualization or at least write down what the changes are so you can track them.  Most importantly, you need the discipline to stop making changes or to push changes to the next release.

 

Iterative Development

I have been involved in a lot of development projects over the past 3-decades.  Projects are successful to the extent that you show them to users during the development effort!  Conversely, they are almost never successful when users don’t get involved.

Create a group of about half-a-dozen committed or excited potential customers who are not afraid to give feedback.  Although I am not committed to any particular development methodology, think Agile!  Right before the end of each major milestone, get this group together and walk them through the application.  Get their feedback and implement changes which make sense and follow the minimum viable product dictum.  This is the place to identify and fix the problems with the lowest time and cost impact. 

 

Test the Software First

As I mentioned above, I have heard the phrase “we only have one chance to get it right” more times than I can count.  It’s true, but it really means when you release the software to customers, it must be bug free!  That means: (1) it must perform the planned functions correctly, (2) it must be easy to learn and use, and (3) it cannot break or terminate abnormally. 

The only way to ensure this is to thoroughly test the software under multiple scenarios.  Thoroughly test each function or page of the application one at a time and work with the developer of that page or function to resolve any bugs before moving on to the next one.   

After you have done that, retest the entire application and make sure it works end-to-end. 

An important tip:  Although it may seem unintuitive, it is important to reduce the number of developers touching the code as you get down to the end of the bugs.  At this point, more developers means more errors.

Once you are satisfied that the software is bug free, provide it to one or two of your customers to use prior to general release (a Beta Test).  Assuming that the software is bug free, you will get good feedback including (1) identification of functions and features that are must haves and need to be added, (2) functions or features that need to be enhanced, and (3) an overall assessment of usability.  Depending upon how critical this feedback is you may want to consider making minor changes prior to general release of your product.

 

Different Environments

Code needs to be kept in different environments such as development, testing, and production.  Once you go live and start making changes, you will need a set of environments for that release as well.  Using GitHub or a similar code management product can greatly simplify this.

 

The Bottom Line

Since I have lived and breathed software development for over 3-decades, I can go on incessantly about this topic.  (If you haven’t had enough, see my other blog posts at “TVenturesCorp.Com/blog.”)  However, the bottom line is that to be a successful business you need to get your software into the hands of your customers!  If you can do that, you have a great chance of success. If you can’t do that, it doesn’t matter how great or elegant your product idea is since you don’t have a product!

 

As a Co-Founder and Principal for Information Concepts, a software development firm, Cary Toor directly managed or oversaw the development of hundreds of software development projects over the 30 years.  Cary recently founded T-Ventures Corp to help small companies implement their software products and projects.  (Cary.Toor@TVenturesCorp.Com). 

Off-Shore Software Development: Increasing the Odds of Success

Posted on by Cary Toor

Posted by Cary Toor

Today, most company that are mid-size or larger are actively developing at least some of their software applications off-shore. This is also a viable option for small, tech-savvy companies. This may include hiring developers, analysts, and/or software testers or contracting the entire project out. Why? The cost, of course: $3,500 per month for a mid-level developer (in India) as compared to $13,000 for a mid-level developer in the US; a 4-for-1 cost advantage for off-shore. Yes, costs are increasing for off-shore resources, but a large cost advantage still exists.

I ran a software development and consulting firm for 30-plus years that was late to the game of using off-shore resource. This isn’t because we were xenophobic or fixated on using only American labor, but because we made a significant business out of fixing broken off-shored projects for over a decade-and-ahalf. The purpose of this discussion is (1) to tell the story of what we learned and how we eventually began using off-shore resources very effectively in both our own development projects and in fixing broken off-shore projects and (2) to provide some general tips that companies can employ to increase the probability of success in their projects with off-shore labor.

 

A Little History

Off-shore software development as an industry is really only about 25-years old. For a very brief history, the trend toward off-shore development seriously started in the mid-1990s during the Y2K and .com bubbles, not just to save money, but to acquire somewhat experienced developers and software testers who were virtually unavailable due to the unbelievable demand in the late 1990s. This trend continued on the other side of the .com bust as global telecommunications improved, off-shore resource quality improved, and the cost for US software development resources ratcheted higher. Off-shore labor suppliers have made it so easy to contract both for labor and complete development projects that virtually any organization of any size or level of expertise can do it. I am amazed by the fact that you can acquire off-shore resources faster than you can hire US resources, and for a fraction of the cost.

Early on, we saw 2 gaps between US and off-shore resources:

  • Skills Gap. In the 1990s and early 2000s, off-shore resources in general had a much lower level of expertise than US resources with a similar level of experience. I don’t believe this has anything to do with superiority of US resources, but instead with off shore resources’ a lack of exposure to complex projects and coding tasks as well as lack of techniques and development patterns necessary to effectively write production software.
  • Culture Gap. In the 1990s and early 2000s, off shore resources did not have an understanding of our business goals, or even business structure. For example, reports were an alien concept in many of the countries typically used for resources and businesses in the US operated very differently from the businesses in the countries supplying off-shore resources.

For that reason, in the late 1990s and early 2000s, productivity of off-shore developers was much lower than productivity of US resources with the same experience levels; starting out at maybe 3-to-1, which was easily justified by the cost advantage that was even wider than it is today. As off-shore developers
were exposed to more projects, more complex projects and better development techniques, and as their own economies became more sophisticated, this factor has been substantially reduced to what I believe to be around 1.25-to-1 today.

 

Out of Sight / Out of Mind

Based on the review of the many projects in which I have been involved, the primary reason for offshore failure is basically the same as it is for US projects: lack of management attention. It is even easier to ignore off-shore projects than it is to ignore a development team down the hall or one floor below where you sit. This includes:

  1. Just like development firms in the US, off-shore development companies like to sell complete projects (as opposed to resources managed by the customer), giving them more flexibility to manage and deploy their resources profitably. However, this requires these companies to impose the project management structure and discipline necessary for project success; something which only the most disciplined companies are good at.
  2. Even routine project problems can quickly blow up due to factors such as opposing time zones (developers working during US down hours), lack of understanding of the business process, and generally, the difficulty in communicating.
  3. Any development project runs into on-going issues such as the need for clarification or additional detail in specifications. Because of time zone differences, the distance of users and the difficulty in communications, off shore teams typically ask fewer questions and make more assumptions. (Everyone involved in software development knows that assumptions are death!)
  4. The most difficult factor in contracting out software development, either on-shore or off-shore, is ensuring that projects are moving forward correctly (i.e. the developer is building what the user wants). Since mid-project reviews and associated feedback tend to be more difficult with off-shore developers, they are done less.

Even with everyone’s best intentions, all of these factors make it easy for projects to go off the rails. The 4-to-1 cost advantage can easily turn to breakeven or even negative if significant rework is required.

 

Tactics to Increase the Probability of Success

There are a number of tactics which we used that significantly increased the probability of a successful off-shore project. These include:

  • Take Control of Off-Shore Resources. I do not believe that off-shoring of entire projects (including project management) is necessarily the best way to go. I prefer a strategy in which the customer hires off-shore resources to staff the project, while the project management and a senior technical resource (and some testing) is maintained in-house by customers. First, this removes the out-of-sight / out-of-mind problem. Second, this structure allows the customer to keep control of the project and project schedule while managing the communications.

Even if your organization is only providing a Project Manager, the best approach is to integrate the off-shore resources into your team structure. Make sure there is an opportunity for daily communications. (For example, if you are on the East Coast, have developers in India start 2-3 hours later and work later 2-3 hours later so you can communicate with them first thing in the morning.) If you have a daily scrum session, make sure the off-shore resources are included. Alternatively, get a detailed daily update via email with any issues that need to be resolved and review them each morning. Maintain these disciplines throughout the project life cycle.

If you want (or need) to contract out the entire project, make sure you have regular (at least weekly) detailed project reviews and be prepared to make users available to the developers.

  • Own the Source Code. One of the biggest problems I have experienced (both with US-based developers and off-shore developers) is that source code is not where it is supposed to be. For US-based developers, this is more easily remedied. For off-shore developers, it has the potential to cause substantial problems (either through everyone’s best or worst intentions). It is impossible to evaluate the work performed to date (or cut off the contractor from the project) if you don’t have access to the Source Code. If you don’t want to open up your organization’s Source Code Control System to outside developers, set up a project in bitbucket, github, or some similar tool and make sure code is checked-in every night. Do a demonstration complete build with the contractor once-a-month. Put this in the contract (see below).
  • Own the Application Testing Process. Clearly, it is beneficial to make sure that anything which comes back from the off-shore team is tested by that team. However, it is essential for the contracting organization to test during every release to identify exactly which tasks can be marked as complete. Releases and testing should be incremental (i.e. once per week, twice per month, etc.) Alternatively, have one company doing the development and another doing the testing.
  •  Requirements / Specification. Make sure that the requirements and build specifications are very clear. In addition to written requirements and specifications, we used medium-fidelity visualizations to make sure that the application will look and flow as desired.

 

Contracts

Contracts with off-shore companies can be very difficult to enforce since, unless the dollar amount is large, there isn’t really any effective enforcement mechanism. That doesn’t mean that the contract isn’t important.  In fact, it is probably more so. In addition to the boilerplate software development contract, the following items are essential:

1. Set the jurisdiction so that it is local to your organization, not in the foreign country.

2. Do not permit resources to be moved on and off the project without your concurrence (or at least notification). It is fairly easy to figure out if resources are being moved around based on (1) the speed at which assigned tasks are completed, (2) the amount of clarification required to correctly complete a task, and (3) the number of assumptions (correct or incorrect) made by the developer for a task. Clearly, a developer working on a project from its inception will have a more thorough background than one coming into the project at a later date.

3. Make sure there are overlapping hours between your organization’s work schedule and the developers work schedule.

4. If you have a daily scrum session (or even a weekly project review), specify it as clearly as possible in the contract (including agenda, estimated length, and who should attend).

5. If you want status reports from developers, testers, or project managers, specify the frequency (daily, weekly, etc.), content, and format.

6. Specify your source code control strategy. Make sure the contract states that all files are to be checked-in at the end of each day. As discussed above, make sure you specify a weekly (or semi-monthly) demonstration build to ensure that the source code is in the correct location.

7. Detail your release strategy (i.e. starting in month 2 of the project, there should be an incremental release every 2 weeks).

8. Identify who is responsible for designing the application architecture.

9. Identify who is responsible for unit and integration testing.

10. If your organization has standards you want followed, make sure they are attached to the contract.

If your vendor will not agree to these terms, there are plenty of off-shore vendors who will.  Find another vendor!

 

Conclusion

Nothing about dealing with off-shore developers should be any different from your organization’s strategy in dealing with on-shore developers. The best strategy for dealing with off-shore developers is to integrate off-shore them into your team and treat them the same as you would your own developers. This will greatly increase the benefit of using offshore developers as well as the likelihood of success.

As a Co-Founder and Principal for Information Concepts, a software development firm, Cary Toor directly managed or oversaw the development of hundreds of software development projects over the 30 years.  Cary recently founded T-Ventures Corp to help small companies implement their software products and projects.  (Cary.Toor@TVenturesCorp.Com). 

 

A Major Reason Why Software Development Schedules Slip and What to Do About It

Posted on by Cary Toor

Posted by Cary Toor

I am going to set some boundaries for this discussion and focus just on the lifecycle phases of Coding/Unit Testing through Integration Testing.  Collecting requirements, the prerequisite for these phases, has its own set of challenges including: (1) getting business stakeholders and application users (which I will refer to as users) to focus on the process, (2) getting users to actually understand the requirements which are identified (which is why you might want to use visualizations), and (3) getting signoff before design and development.  For the purposes of this discussion, let’s assume that the requirements collection process was a success (meaning that the requirements collected actually come close to what needs to be built).  I am also going to push User Acceptance Testing (UAT) outside of this discussion, since it deserves its own in-depth analysis of its impact on scheduling, delays, and customer satisfaction.

If we lop off UAT, I think it is a reasonable assumption that a typical projects break down roughly as follows:

  • Requirements and Design: 25% – 30% of the project effort.
  • Coding and Unit Testing: 50% – 60% of the project effort.
  • System Integration Testing (SIT): 25% – 30% of the project effort.

Once the requirements are collected, the process for creating a project plan is basically as follows:

  1. Group the requirements by functionality
  2. Break the project down into modules (or Sprints in the Agile world) containing related functionality
  3. Devolve modules into specific coding tasks
  4. Estimate the time required to complete the coding and unit testing for each task
  5. Estimate the time required for Module-level and System Integration Testing.

It is my belief that most experienced senior developers are fairly good at estimating how long a coding task will take in their environment (and may even over-estimate the time required).  Of course, project plans developed with more granular tasks that have fewer external dependencies can be estimated much more accurately than project plans developed with more expansive tasks that have a higher number of external  dependencies.  So, build your project plan with that in mind.

If, as I previously suggested, senior developers are pretty good at estimating the time required for development, why are projects always falling behind schedules?  Where may be good at estimating coding time, we are terrible at estimating the testing time!

Whether development is done using Agile Sprints or traditional milestones, at the end of each related series of tasks it is necessary to test the modules to make sure that all of the individual tasks work together.  I will refer to this Module-level Testing.  This is the root of schedule breakdowns. 

 

Scheduling Considerations for Testing

Before I talk about Module-level Testing, I want to take a short detour and discuss two factors which drive the time and cost of testing:

  • One of the major themes of successful software development is that testing is most likely to find and resolve problems (issues, bugs etc.) quickly when (a) done on small pieces of code and (b) done closer to the time of actual coding. The corollary to this is that as a project moves further away from a coding task and into larger pieces of code, testing is more difficult, more time consuming, more expensive, and less predictable (as shown in the table below).  This means that successful scheduling requires that problems are identified as close to the coding task as possible.  
  • Testing is a cycle which generally works as follows:
    • A QA tester (typically either an analyst or QA person, but not a developer) tests the application, identifies a problem, and documents that problem for the developer to fix.
    • The developer attempts to duplicate the problem. If the developer can duplicate the problem, he or she can resolve that problem. If the developer cannot duplicate the problem, he or she will send it back to the QA tester for more information. 
    • The QA tester verifies that the problem is resolved. If the problem is not resolved, the tester will document the issue and send it back for the developer for resolution.  If the problem is resolved, the QA tester will close the problem and move on.

Although this is a straightforward and standard process, it is the number of iterations through these steps for a single problem that can kill a project schedule and budget.  In my own measurements of this process over a large number of projects, I have found that the top 25%-30% of developers can resolve a problem in 2 iterations or less (but never in 1 iteration).   In general, a strong team of a QA tester and a developer can reliably close issues in 3 iterations or less.  A weak QA tester and/or developer can push this into the area of 4-plus iterations. 

 If a project can close problems in 2 iterations or less on average, the test/fix cycle will take half the time it would take if it averages 4-iterations (or be able to fix double the number of bugs in the same amount of time).

 

Module-Level Testing

Moving back to Module-level Testing, let’s start with the assumption that the Coding phase of the project includes unit testing, which ensures that each coding task (a) does not break and (b) meets it associated requirements.  This needs to be done by the developer immediately after the completion of coding and prior to the developer moving onto another task.  Alternatively, unit testing could be done by a QA tester in conjunction with a developer, but this is not the standard approach due to (a) a lack of testing resources available on a typical project, (b) additional time required in the schedule, and (c) significantly increased cost.

For unit testing to be effective, each individual task in the project plan needs to be defined so that it can be tested independently of other tasks (as much as possible), either using automated test cases or manual testing.  Unfortunately, for whatever reason (including the fact that unit testing is nobody’s favorite activity), many times unit testing is done poorly or not at all, and the developer moves on to the next task before properly completing the unit testing in the prior task.

Module-level testing should be done by someone other than the developer, such as an analyst or QA tester.  Since unit testing is typically done by the developer, this is the first time someone other than a developer will put his or her hands on the code. 

We can expect the following issues to come up in module-level testing:

  • If the developers (or even one developer) haven’t done a great job of unit testing, this is where the remaining unit test problems will most likely be discovered and resolved. Fixing unit test bugs during time reserved for module-level testing takes time away from module-level testing.  Further, to keep the project on schedule, this level of testing becomes much less thorough than planned (which will cascade to Integration testing down the road). 
  • Because individual tasks are brought together, this is typically the first time that work flow and business logic can be tested, causing the identification of inconsistent and/or incomplete requirements, and bad assumptions on the part of the development team. In many cases, requirements clarification is needed, a process which can cause a significant time lag while talking with and building consensus among users. 
  • In Agile development (and hopefully in more traditional development methodologies as well), completed work is shown to the users at this point for feedback. User may request changes which, even if relatively simple to implement, don’t typically get thoroughly tested, cascading additional problems down the road to Integration Testing. 

All of these issues are difficult to put into a project plan and very difficult to forecast.  However, the pattern is clear.  Problems not resolved in Unit Testing reappear in Module-level Testing, where they are more time consuming and expensive to resolve than they would have been during Unit Testing.  Moving forward, issues not resolved in Module-level Testing will reappear in Integration Testing, where they are yet more time consuming and expensive to resolve.

 

System Integration Testing

In System Integration Testing (or just integration testing for short) all of the separate modules in the application are brought together and tested.  The project will experience the same problems as it did in Module-level Testing, although magnified by the larger amount of code and further distance from the original coding task.  In other words:

  • Unit test bugs not found in unit testing or module testing will cascade down to integration testing.
  • Module level bugs not found in module-level testing will cascade down to integration testing.
  • Additional work flow and business logic problems and inconsistencies will be discovered at this point and may require additional consultations with users.

If the project did a poor job of unit testing, which reduced the amount of time available for module-level testing, the number of problems cascading into integration testing will increase.  The amount and number of these problems is difficult to predict and schedule for, and resolution is more time consuming, and expensive at this point. 

During testing, developers typically work from a list of issues with a limited amount of time to fix each issue.  As discussed above, it takes multiple iterations to close these problems, with increasing iterations increasing time and cost. Additionally, each fix attempt may cause new problems somewhere else in the application.

Another complication at this point is managing project staff.  As you get closer to the deadline, it is everyone’s inclination to add, and certainly not to reduce, staff.  Many times at this point in the project, the business people responsible for the project are putting pressure on the project team to add resources to get the project wrapped up. Unfortunately, this is not the best strategy and may even introduce substantial delays. 

I have found through a lot of experience that early in integration testing the best strategy is to get the original developer to fix problems with his or her code and reduce the number of touches on any individual piece of code.  Additional “hands” who do not understand the application or the code have a long learning curve at this point and are typically detrimental, not helpful.  As the deadline gets closer, the more hands on the code, the more likely it is that new problems will be created.  This spawns the deadly cycle of fixing one problem and creating another problem somewhere else in the application. 

To eliminate this problem, the project team needs to get smaller, not larger.  Only one developer can be touching each related section of code at this point.  This is essential to getting the project completed!

 

Some Basic Rules

Although I mentioned many of these solutions above, I wanted to summarize some of the concrete steps a development manager can take to reduce the testing problem and, hopefully, keep software projects on schedule.

  • When defining project tasks, make sure they are small pieces of the application, not requiring more than 1-2 days of development. Attempt to limit the dependencies with other tasks and architect the application so that each task can be tested on a stand-alone basis.
  • Verify that unit testing is actually being done and, when it is done, that it is being done thoroughly. I recommend the following:
    • Randomly select coding tasks in which a QA tester works with the developer during unit testing. This will, hopefully, make unit testing better without the resources needed to have a QA tester actually perform unit testing for all tasks.
    • Use automated test cases and have the developer define these case prior to starting development (although you will need to ensure that the test cases thoroughly test the requirements).
  • Make sure that testing at the module level is thorough. Don’t let the project move forward unless Module-level Testing has been completed.
  • A large percentage of the uncertainty associated with testing is related to the number of iterations it takes for a bug to get resolved. Make sure that the documentation provided by your QA tester to your developer is complete and accurate.  This is definitely worth some training time.
  • As the project winds down, do not increase, but reduce the number of developers touching the code.

These rules can make a substantial difference in your ability to meet project schedules.

 

 

A Short Path To Better Hiring!

Posted on by Cary Toor

 

Posted By Cary Toor

For a start-up or small business, hiring is one of the most important and most difficult tasks you do. In an organization with only a few employees, there is no place to hide. Everyone’s job is important and everyone’s contribution is essential. The wrong hire can literally kill a company!

I especially see my start-up clients having difficulty hiring. Sometimes they get very skilled employees who are difficult to work with (malcontents, drama queens, and people lacking flexibility). Sometimes they hire people who can’t do the job and can’t grow into it fast enough for a small company.

Owners may have expertise in one or two areas, but they don’t have expertise in many of the jobs which they need to fill. Many times, we come up with tests (or grab them from the internet) to judge potential candidates. Although this can be helpful, it is pretty difficult to align tests with actual skills and they are only one indicator of a good or great employee. 

 

Some Indicators of Great Employees

Over my 3-plus decades running a 50-person software development company, I hired hundreds of staff members. I was good at spotting hard skills, but not so good with soft skills like communications and team work. Over time, however, I came up with a few indicators that made hiring much easier and better identified successful candidates. 

  1. Will the candidate love his or her work?
  2. Does the candidate want to learn new skills in their field?
  3. Is the candidate flexible?
  4. Most importantly, is the candidate a “human” (i.e. not a jerk)? Do you want this person in the cubicle next to you?

Make sure the candidate loves his or her work! I have never had an employee who loves their work and was not worth their money, or better. If you are hiring a software developer, they need to love to code, even to the extent that they code at home for fun. If you are hiring an analyst, they need to love to write or be jazzed by learning about business processes. How do you tell if someone loves their work? 

  • Ask them! Do you love to code? Do you like to write? Is accounting the most interesting thing in your life? 
  • Ask them to tell you about the most exciting thing they did in their career. If they love their work, they will show a lot of excitement. 
  • Ask them to describe their ideal job/work environment. If they describe a different job than the one you are hiring them for, they probably are not a fit.

Make sure the candidate wants to learn new things in his or her field or expand his or her professional horizons. You may need a C# developer, but does the candidate want to learn more about databases, or Java, or other related areas? In a small company, you can’t afford an employee who only wants to stay in their small niche and not expand their skills and knowledge. 

Flexibility goes along with this. How well is the candidate likely to adapt to a changing environment? Are they willing to change teams, work on different projects, or use different methodologies? You can find this out by talking to them about these issues. 

Finally, and most importantly, make sure the candidate is a “human,” my code word for not a jerk. Of course, the definition of a jerk is different for everyone so, try to get the following:

  • Is the candidate likely to work well with other people in your organization?  Is he or she likely to work well with you?
  • Does he or she provide information freely or are they information hoarders? 
  • Are they malcontents or likely to cause trouble? 
  • Do they bring along drama? Will they start rumors or talk behind other employee’s backs?

This can be difficult to determine, but if you ask the candidates about why he or she left their previous positions, you might get some very good clues. You don’t want to hire people who speak poorly about their previous employers or complain incessantly about aspects of their previous positions. Ask the candidate whether he or she would be happier working on a team or individually and how they see themselves participating in a team. Talk to them about the importance of following the rules of a team, such as attending team meetings, coding to standards or writing using a template that someone else created. 

Additionally, talk to everyone (recruiters, receptionists, etc.) in your organization that had contact with the candidate. Did he or she show respect and curtesy to everyone up and down the line? If not, you don’t want them! Before we met with a candidate for a technical interview, we asked our recruiter and HR person to try to figure out if they were a human. 

Of course, to get this information, you need to interview. In person is best, via video conference (Skype, Facetime, etc.) is next.  Voice only is bad since visual cues for both sides are lost. 

 

The Role of Money

Money is very important, to both you and the candidate. Let’s face it, money is always tight (and even if it is not, you should be running your business like it is)! The less you have to pay for an employee the better. However, if you pay less then you need to, you might not get what you want. If you pay significantly less than market value, your employee will leave at the first opportunity.

Ignore the salary surveys. Ask candidates their current salary and their desired salary.  One major advantage of this strategy is that you will have a much more complete understanding of the market and what you need to pay to get what you want.  Remember that you are hiring in a market.  You are comparing the candidate to other people you have interviewed and the candidate is going to compare your offer to other potential offers. 

It is really difficult to hire someone for less money than they want to make (although in a start-up you can convince them that stock options are worth more than the difference). If you do hire someone for less than they want, don’t be surprised if they continue to search for a higher paying job even after you hire them and they start work. Hiring someone for less than they want can also breed resentment, even on day one. If you want to hire someone for less, you need to explain to them why and sell them on the benefits of your organization.

 

Some Final Thoughts

Hiring is difficult, time consuming, and expensive, so it is important to get it right as often as possible, even though we can’t get it right all the time. Try my four indicators for identifying great potential employees. They definitely worked for me (most of the time).

Finally, when you hire someone, make sure you give them a written offer clearly spelling out the terms. They won’t be around long if you have one view of your offer and they have another.

And remember, it is easier to retain great employees than it is to find them!

Why We Can’t Build Software

Posted on by Cary Toor

Posted By Cary Toor

About a year ago, I had an in-depth conversation with some very experienced, very smart people involved in building business software applications every day. The focus of the discussion was which project management strategies worked and which didn’t. Unfortunately, the discussion ended on a very down note; everyone around the table believed that projects rarely, if ever, end with a satisfied customers (or end user), even when virtually 100% of the requirements are met.

This is not a surprise, as the typical opinion of business people is that software developers never get it right, that all projects end behind schedule and over budget, and that the customer has to settle for less than they want, no matter how simple the application, how big the budget or how long the schedule.

In 1994, the Standish Group published the first version of its Chaos Report (which it now publishes yearly). Based on the findings of the study, the “Chaos Report” was a great name! The report concluded that only 16% of all software development projects were completed successfully, 53% were over budget or lacked key features, and 31% were complete failures. Today, 20 years later, this hasn’t improved much. The 2015 survey, with easier criteria, found that 29% of all projects were successful, 52% were over budget or lacking key features, and 19% were total write-offs.

Regardless of the findings, I think my friends are wrong and that software projects do not need to end with unhappy customers. I have run a business focused on building business software applications for both public and private sector customers for 34-years. Besides becoming old, I have been involved with a large number of projects, mostly successful, with over 95% going into production in the last 5 years. This experience has demonstrated to me that there are strategies which can be employed to dramatically improve the rate of success for software projects.

The purpose of this discussion is to explore some of the deficiencies called out in the Standish’s Chaos Report and discuss some of the strategies that I have seen which can improve the chances for project success.

 

Building Bridges vs. Building Software

The first Chaos Report compares building software to building bridges. It makes the point that if bridges were built like software, there would be a lot more cars falling into the water. In discussions with my project managers, I have frequently compared building software to building a house, but neither is a reasonable comparison.

  • When building a bridge, there is a fixed objective: connecting physical points in which the geography is known and never changes. In building software, the objective can easily change: collecting orders through an order entry system can easily morph into supporting an e-commerce front-end and managing fulfillment. There are no physical boundaries.
  • When building a bridge (or a house), all of the requirements and architecture work are done before construction starts. When building software, even if requirements are all collected correctly up front, requirements and architecture rarely remain the same from the start of the project to the time it goes into production. 
  • The process of drawing plans (and blueprints) for a bridge is standardized.  There are a lot of people trained to understand and review these plans. For software, the process for defining requirements and sharing those requirements with users is not standardized and there are very few people trained to understand them (or who even have the patience to look at them). 
  •  There is a set of rules (or standards) for building a bridge. Software development has no universal set of rules (standards) and, even when standards are present, they rarely enforced.
  • When building a bridge, any changes are taken very seriously, with physical design changes  being made to the architecture before any construction changes are made to the bridge.  When changes are identified, the bridge project is then re-scoped. When building software, changes are taken less seriously, the changes are not necessarily reviewed against the original architecture, and the project is rarely re-scoped when changes are made.
  • And so on…

Most importantly, though, in physical construction there are architects and engineers, each responsible for their own functions and each providing a check on the other. This type of team structure does not really exist in software development. 

Building a bridge or a house is about the mechanics for building the bridge or house (1) designing the bridge or house, (2) building the bridge or house, and (3) ensuring that the bridge or house is well constructed and follows the building codes. Each step is very focused with specific personnel dedicated to the process. 

As the Chaos Report points out, building software is not just about process, which is not standardized in software development. It is about the quality of the Team. Important factors identified by the Report include a standard architectural management process, a staff that has skills in both business and technology, and a design which is based on what Standish calls “modest execution,” which means translating the requirements into simple, well defined pieces that are then strung together to create the software application.  

Finally, the costs associated with physical construction (and reconstruction in the event of a mistake) are substantially greater than the comparable costs of building software.  This is one of the reasons that there is a lot more staff, training, and structure in building bridges and houses than in building software.

 

Business Rule Hell

Everyone in the software development business has heard customers say: “There are over 2-million apps in the App Store. Why can’t we get our application built?”

The difficulty with business applications is that they have business rules which define how the application operates. For example:

  • The user must enter a number between 1 and 10 into the items purchased field.
  • The Ship date displayed to the user must be greater than the current date but must be calculated based on total order backlog and staffing available.
  • When a user selects an item for purchase, the number of items in inventory must be greater than 0. If the number of items in inventory are not greater than 0, the item must be automatically placed in back order status to be fulfilled upon receipt of new inventory items.

In even a very simple business application, there can easily be thousands of business rules. Frequently, as these rules are collected during the requirements phase of a project, they are incomplete, incorrect, or contradictory. It is difficult to identify these problems during requirements collection, and many times they can only be seen after the user has looked at actual application and can see the results of all of the business rules which were implemented (i.e. during user acceptance testing). Even if these rules are implemented in a way which is easily altered, testing with incorrect rules shakes user confidence and causes a problem with user perception of the software quality.

This is in contrast to most apps in the app store which are focused on a single, simple process and have a very limited number of business rules. Bridges do not have business rules, nor is there an expectation that they can be flexible like software applications.     

 

Why There is Hope

I strongly believe that today, from a technical perspective, we know how to design and efficiently build software applications using the tools available. It is many of the human factors — such as collecting requirement, over complicating designs, and performing incomplete testing — which cause the problems. 

I can spend a lot more time defining the problem, but I would rather talk about some solutions.  A brief list of some of the most important and straightforward strategies for success are listed below.

  1. One of the most important strategies is to have an analyst on the development team who understands (a) how business processes work in general, (b) how the business process around the application should work, and (c) the actual work flows required to implement the business processes of the application. This is typically not a technical person, as the vast majority of technical people I have met do not think this way.    In the Chaos Report, Standish referrers to this idea as the maturity of the team.   
  2. Business users need to be shown what they application will look like before development starts, using processes like prototyping and visualization. If the user can actually view the user experience prior to development, this significantly reduces the number of changes during user testing (although it will not eliminate them). The users really need to understand the requirements, and prototyping and visualizations are a simple way to provide this understanding.
  3. Typically, the customer (or end user) is not relieved from their day-to-day duties during critical portions of the software development life cycle, such as requirements definition and testing. This means that supporting the software development team becomes extra work for the customer. The customer commitment needs to be defined up front by the development team and customers needs to accept this commitment.   
  4. The design of the application needs to be simple, easy for developers to understand, and both technically and visually consistent.  An example is a user experience comprised of a summary page followed by its associated detail pages (in other words, a hierarchical structure). Although this might cost users a few extra clicks or pages movements for a complex transaction, it is worthwhile to ensure that the developer understands what he or she is building. This strategy allows for a Senior Developer to build model pages that all other developers can work from.
  5. Like the design needs to be simple, it also needs to be modular. Every page or business flow should be run and testable on a stand-alone basis. Ideally, there needs to be one way into a page or flow and no more than one or two ways out of that page or flow.   
  6. Invariably, the development schedule and budget are based on available time and resources. This is planning for failure – and bridge construction would never be planned this way. The bridge would be scaled back to meet the budget and schedule or the budget and schedule would be expanded. Unfortunately, the plan needs to be a realistic representation of functionality, time, and cost.
  7. The end users need to be involved in testing (User Acceptance Testing) and the development team need to plan for and budget to make changes to business rules, and potentially other functionality, during testing.  

 

Evolution Improves Everything

Yes, evolution improves everything. Invariably, we try to put every feature and capability into Release 1 because there is never a concrete commitment to a Release 2. Think about commercial software products you have used and how they have improved over time. 

 It is unrealistic for the customer or development team to believe that the application will be perfect in Release 1. As software applications go through additional releases, capabilities can be added, functionality can be enhanced, and usability can be enriched. 

Evolution can save time and money as well as make it more likely that software applications will be delivered as scheduled with planned functionality.

 

My Conclusion

If you have read this far, you know that I am optimistic about our ability to deliver software projects as planned. I strongly believe that using the development strategies briefly discussed above, it is possible to deliver business software applications as planned and budgeted. Given the failure rate in the industry, it is definitely worth a try!

Never forget: bridge building is physical; we can see all parts of it as it is being built. Even though we strive to make software development more physical, it is not, so we can’t see it until all the pieces are complete. This can make complex software much more difficult and costly to plan and build than a bridge.