Advice
Invaluable Tips & Information

Advice to Banks and Credit Unions for Establishing Website Development Budgets

If you're in charge of determining a budget for website development & ongoing management for a bank or credit union, the most critical success factor is ensuring you follow a reliable formula. One such formula is:

Reasonable Expectations + Reasonable Budget = Likely Success

“How much should this project cost?”

That’s an important question and it's critical that you involve the people most capable of answering that question accurately early in the process. In nearly all cases, you'll need key technical, creative, and management people with expertise in the technical processes, as well as the strategic & tactical goals of the organization to arrive at a reliable answer.

Should I Be Secretive About My Budget?

No, not usually. Developing custom websites is similar to building a custom home. There's a big difference between a $100,000 house and a $5,000,000 house and the same is true of websites. So when you hire a home designer, the it's important to share budget early so the designer can properly advise you. Likewise, if you tell your prospective web team your budget constraints, a competent team can best advise you on how to get the most value from your budget.

Share as much information as possible with your prospective partners up front. Important questions to answer include:

If the project is successful, how much value will the bank or credit union realize?
What is the value of each key goal, if successful? If financial or other resources are constrained, which opportunities present the highest value and least risk?
What are the opportunity costs associated with either acting or not acting?
What key dates or deadlines are critical to realize full benefit of the opportunities?
What resources are available and to what extent will the team be able to use them?

An experienced team can help you properly scope your project to fit within your budget. For example, if you have a budget of $50,000, then a good team will recommend only options that they can achieve in that budget and will help you prioritize features to maximize your return on investment.

By sharing your budget limitations early and openly, you will save yourself time by allowing your team to present realistic solutions that fit within your budget.

Why do estimates vary from one team to another?

In my career, I have worked on websites that had budgets ranging from $5,000 to millions of dollars. While a $5,000 website and a million dollar website are both websites, the effort to produce them and the functionality in each is vastly different.

When a team lacks accurate, detailed requirements, they must make assumptions about your goals, resources, value, and constraints. Assumptions vary widely from one person to another and one team to another, which results in estimate variances. This forces you to compare apples and oranges when choosing a partner or solution.

Real World Example of Drastic Cost Estimate Variance

When you ask a developer to estimate the cost to create your website or mobile app, the estimate will largely depend on three factors:

Specific functionality of the website or software
Types of skills necessary to build the functionality
Billing rate for each of the people involved

Assumptions about functionality differences are often the cause of estimate variances between equally capable teams. Your vision for a “Branch Locator” or “ Secure Login” may be radically different from that of the programmer who is reading your request for proposal. Whenever possible, avoid ambiguity.

The best way to avoid ambiguity is to have in-depth conversations during the proposal phase with the teams you might work with on the project. Experienced teams will ask critical questions that help to ferret out details to determine realistic, accurate budgets.

Let’s look at a common example that will illustrate how two different development teams can estimate one set of functionality very differently.

“Login” Example

Let’s suppose that you want to hire a development team to build an online customer portal. On your requirements list, you include the following feature:

“Requirement #1: A user should be able to login to the customer portal”

You contact two different development teams for an estimate. The estimates you receive back are:

Team A - $300 (2 hours)
Team B - $4,500 (30 hours)

WHOA, that’s a big difference! What makes Team B’s login feature so much more costly than Team A’s?

How Assumptions Drive Estimates

Let’s assume for the sake of this example that both teams are equally competent and both work at the same pace and roughly the same hourly rate. If both teams work equally fast and have comparable skills & hourly rates, why are the estimates so different?

To understand the difference, we need to examine the assumptions each team made about your very concise login requirement.

Team A’s Estimate

Their assumptions:

You will ask the user for only for a username and a password
Username and password values will be stored in plain text in the code
There are no rules about the length, complexity, or expiration of a username or password
A user can attempt to logon as many times as he wishes without ever locking out the account
No audit log will be kept of failed or successful login attempts
No feedback will be returned to the user if he enters an incorrect username or password, rather the login form will just reload with blank inputs if the login credentials are incorrect

Team B’s Estimate

This team approached your requirements with an assumption that you wanted a high level of security, user-friendliness, and a lower long-term support and maintenance costs. Their assumptions:

Users will logon with a username and password
Multi-factor authentication will also be available for each user account
Username will be stored in a secure SQL database
Passwords will be hashed and only the hashed value will be stored (as opposed to the real password), which is impossible to decrypt and very nearly impossible to crack.
The app will prompt users with a challenge question when logging in from a computer that the user has not previously logged in from.
The system to automatically lock an account after a certain number of invalid attempts
To aid users who have lost their passwords, Team B’s estimate includes an automated password reset procedure.
Team B also assumes that you’ll want a way to manage your users without having to edit the programming code, so they’re planning to build a secure administration portal for the application.
Team B knows that keeping a good audit trail of system access is important to security conscious companies, so their estimate also includes writing code to record a log of all activities performed on the website, including failed login attempts, password changes, password resets, and many other common security related activities.
Team B also assumes that you want to lower the risk of introducing bugs into your website as you add new features, so they’ve planned to build automated tests into their code that will execute every time your website is deployed. This will help to prevent new code from breaking existing functionality.

Same Name, Very Different Results

The example above is one that we encounter often in our practice and illustrates clearly why you can receive widely varying estimates to develop something as common as a “user login.” Both feature sets described above meet the criteria for allowing a user to login; however, Team B’s approach will clearly require more time and cost, but you may see more value in one approach versus the other.

Candid Budget Disclosure Can Create Greater Value

Most development teams I have worked with want to maximize the value of the software they create. With a trustworthy, capable team, there is very little risk of a team delivering less value than you’ve paid for. The opposite is usually true, especially if the team you’ve hired knows that you’ve been honest, you’re easy to work with, and they believe you respect them.

I can speak for the team here at Inet, and others I’ve worked with, when I say that we all genuinely love to help people succeed. Building custom software is a profession based on serving others. We build technology that millions of people use every day to make their jobs and personal lives easier to manage, more secure, and less aggravating. I also see the hundreds of hours that Inet team members put into projects for our clients that never show up on an invoice, simply because the men and women here enjoy helping those clients, even if that means doing work that the client cannot pay for. The team members here simply do it out of a love for the work and helping others. The people who are most likely to receive these benefits are, not surprisingly, those who have built relationships based on openness, trust, and mutual respect. I cannot speak for all people, but here at Inet you’ll definitely earn a return on your investment in openness.