Estimating Software Development

A recent software development project served as a prime example of what can go wrong. The project was late and over budget. So who is to blame when such a situation occurs?

I'll outline the scenario and let you decide:

The project was defined by the company to solve a specific problem. There is no commercially-available software product that could be acquired or even retrofitted as a solution, so the specialized software system had to be built from the ground up.

The contract programming firm met with the key users to get a feel for the project requirements and scope. After the meeting, a high-level overview of the project was prepared, with an estimate that included the approximate number of programs and high-level functionality that would be required.

Based on that document and subsequent meetings, a development estimate was prepared. The estimate was clear about the scope of the project, including the maximum number of programs to be included in the project.

When the estimate got to the customer's management team, a key approver decided it was too expensive. He called the vendor to try to get the cost lower. The vendor, of course, maintained that there were only two ways to lower the estimate: Cut back on scope or cut back on the hourly rate. And of course, the hourly rate was as low as the vendor was willing to go.

So partly because of the manager's insistence, and partly because the vendor didn't want to lose the business, certain assumptions were built in to reduce the scope of the project and bring the total estimated number down closer to the manager's liking.

The project got underway, and moved along through the analysis and design stages. Development began, and of course at some point it was realized that the scope would indeed be exceeded. In fact, the scope in terms of number of programs had gone up by nearly a factor of 2. The Project Manager was pretty certain the project scope was unrealistic as soon as the initial analysis was complete, but the Vendor manager asked him to hold off on raising it as an issue until he was certain the project would go over budget.

So when it became clear the project would exceed the allotted budget, an analysis was performed and a revised estimate prepared. Even so, due to the creativity, extra effort, and efficiencies realized from the key development team members, the revised estimate was not double, but was almost exactly the same as the original estimate.

The same manager's response was anger and outrage. How could the vendor have gotten it so wrong? When the vendor meekly pointed out that the reason for the increased estimate was that the assumptions made in response to his request to scale back the original cost turned out to be invalid, the manager suddenly developed amnesia.

So in the interest of keeping the customer happy, even though the project was cleary contracted as a Time & Materials agreement, the vendor made concessions to cut their profit margin to bring the project in at a total amount that basically split the difference between the revised estimate and the actual projected cost.

Coming back to the question leading into this story, who is to blame for this project going over budget?

Is it the client manager's fault for unfairly forcing concessions from the vendor when they clearly demonstrated that their original estimate was correct and was only reduced at his insistence?

Is it the vendor's fault for giving in to the manager and reducing the estimate, even though they knew the actual cost was likely to come in at the original estimate?

Is it the Project Manager's fault for failing to strongly protest the project budget immediately after initial planning indicated the budget was unrealistic?

What should the vendor learn from this experience?

So You Think You Need Software

So you think it's time to find and implement some new software for your company. It's a big decision. Software projects for medium to large organizations can easily spiral into hundreds of thousands or millions of dollars.

That's the real decision, and the first question:

Can we implement software that will pay for itself?

I'm amazed at how often the answer to that question, only discovered well after the project is complete, is No.

Let's explore several actual reasons companies have bought and implemented new software.

Good, Solid Reasons:

• Opening a new business that has to have software to operate.
• Business Growth has caused the company to outgrow its current small business software.
• New requirements of the business are not met in the current software.
• The geek guru who takes care of the homegrown software has quit or retired and nobody knows how to maintain his code.

Why they're not always Good or Solid Reasons:

Often, new businesses are opened by larger corporations or holding companies. Sometimes the wise executives at the top think they can save money by just having the new division use the same software they have back at the corporate office. More likely, that corporate software in the new division is the proverbial square peg in a round hole. It just doesn't fit. The company might end up spending hundreds of thousands of dollars trying to find the right hammer to pound in that square peg before finally figuring out they need something else.

Business growth is usually a great reason, but is it always a reason to scrap the old software? For example, if the business has expanded internationally, the current software might not support multiple currencies or international payroll. Maybe a better answer in that case would be to find new software for the international divisions and build interfaces into the Corporate system, which still works fine domestically.

New requirements might not by themselves justify replacement of the entire system. The old idea of throwing the baby out with the bathwater comes to mind. Analyze what are those requirements? Are they really business requirements or manager preferences? It might be cheaper to develop or buy a smaller solution that can meet the requirements and be integrated into the rest of the software than to take on a whole new software project. First of all, don't forget to check in with your existing software vendor - perhaps they have met those new requirements recently and you simply were not aware.

The geek guru is a situation companies can't afford to allow these days, but clearly many still do. No company's systems should be at the mercy of a single programmer, who has the power to bring the system crashing to earth simply because he's having a bad day. Replacing that homegrown system with a packaged solution probably is advisable in most cases, but in the meantime it would be prudent to get that in-house system independently reviewed and documented.

Poor Reasons:

There are plenty of bad reasons for implementing new software. Understand, these may not be bad reasons if included on a list of other very good reasons. But by themselves, these should never be the deciding factor in trading in software.

• Boss's Pet: The new boss came from another company where she used and loved Super Software (name made up). She almost immediately demanded the current software be replaced as quickly as possible with her beloved Super Software.
• Keeping Up with the Joneses: The idea being promoted by certain very high-profile software vendors these days is that the best companies run their software, and if you don't you're toast. Never make a multi-million dollar decision based on a vague perception of trendiness and status.
• Sold on DemoWare: The terrific salesperson came into the executive suite and gave a software demonstration that knocked the management team's socks off their feet. The demo was so great the agreement was signed on the spot.
• Technological Bigotry: The new CIO came in and demanded that the current systems be replaced, because those in place are old or obsolete. What he's really saying is that he hasn't worked with those servers or database platforms before, and doesn't want to start now.
  

Reasons that May be Good or Poor:

• Dispute with Software Vendor: If the dispute is irreconcilable and can cause harm to the business, maybe it's necessary to move off their software as soon as possible. If your CIO can't stand the jerk the company assigned as your Account Exec, maybe it would be better to ask the software company for a new Account Exec.
• Technology (without the Bigotry): Perhaps the systems really are based on outdated technology. The hardware it must run on is no longer supported, or there hasn't been a new release in years, or the character-based interface has not been upgraded to a graphical or web browser. On the other hand, see the Technological Bigotry in the previous section.
• Standardization: Many organizations find themselves in situations where their various business units use several different software solutions. As companies are acquired and absorbed into the organization, they bring their existing software products with them. Often a standardization to a single ERP solution makes sense, where the organization is relatively homogeneous. But if the various business units are divided among different industries and/or allowed to operate independently, moving everyone to a single standard ERP may not be the right solution.

So you think you need some new software?

Just make sure you ask the right questions first.

Welcome to the Software Project Manager's Blog

Welcome to the beginning of the blog by and for those who manage complex software implementation projects.

This blog is dedicated to the joys, challenges, and lessons learned from a quarter-century of experience in managing software projects.

The topics in this blog will cover software selection. estimating, team dynamics, scope management, risk management, communication, and practical lessons learned about delivering successful software projects.

Feedback is encouraged and solicited.

I hope you enjoy the blog.