Initial Consultation / See if a Project Makes Sense
Who you’ll work with: Business Analyst / Software Architect
Time for this stage: Varies by project size, usually between 30 and 90 minutes for initial
consultation with a new client, sometimes only 2 or 3 minutes to
check on feasibility for a simple addition for an existing client
Cost and Billing Type: Initial consultation call is free for new potential clients, often covered by maintenance contract for existing clients,
billed hourly otherwise.
Output of this stage: An estimate of the return on the project (how much time/cost saved, how much more money made, etc.), an estimate of the cost and timetable
within a rough factor of 2 (so "80k to 160k" or "15k to 30k", etc.), and a determination if the project makes sense by comparing the two.
Before we start any development work, we first determine if a project makes sense. For new clients, that starts with a free initial consultation
call by phone or Skype usually lasting between 30 and 90 minutes. Our first questions are along the lines of
"What would you like to build?", "What’s your organization like?"
and "What are you trying to achieve?" A new customer’s top question is usually "What would my proposed system cost?" After a first call we
seek to have at least rough answers to all of those questions.
In this stage, sometimes feasibility is easy to calculate. If we’re asked "Can you build a functional clone of Facebook on a budget of 200k?" The answer for that is "no." (We’ve been asked!)
Or sometimes we’re asked "Can you create a system that will fully automate all of the office tasks for my one person business?" to which the answer is
"Yes, we could automate all of that, but the amount it will cost vs. the amount of time it will save doesn’t make sense. It would take more than 10 years for that investment to pay off. You’re
better off saving the money, hiring a part time admin person, and then calling us again when you have 5 or 10 people instead of one." But if we hear "We’re a small, rapidly growing organization,
and we’re getting buried under the new work because our tools are so inefficient," then that’s a much more promising situation, as automation will reduce the rate of growth of staff
costs while unleashing time for the staff to accelerate growth.
In an initial consultation we also check with a client to make sure custom software is a good fit for them. Have they tried available off-the-shelf alternatives? Why
not use one of them? If the answer is that the client should use an off-the-shelf solution, they go away happy and we have good will toward us in the future. If the answer
is that the client shouldn’t use an off-the-shelf solution then the reasons they explain why not help us zero in on what they’re trying to achieve and what they need.
We also share ideas on achieving a client’s goals. Recently a potential client contacted us to explore software for a new startup, but their budget wasn’t up to what they
were wanting to do. We came up with a way to do it for half of what other firms were quoting by coming up with a better approach, but that still wasn’t in this
group’s budget. But that didn’t matter, as in our judgement this particular client needed to focus first on building an audience for their ideas, not yet focus on building software.
So we suggested starting with online blogging and content creation around their idea, building an audience, and connecting with future customers, and validating first
that there is both interest in their idea and people willing to pay for it. (The particular idea was a good fit for this approach.) So in this case we actually ended up
telling the potential customer "You don’t need custom software, you need to start writing and engaging an audience in the ideas around your startup." If they can draw an audience,
they can get to making software for it. If they can’t draw an audience, software development would be wasted money.
1. Determine What To Build
Who you’ll work with: Business Analyst / Software Architect, Development Lead, Designer for some projects
Cost and Billing Type: Typically between 8 and 15% of total project cost. Billed hourly or weekly, depending on project size, for costs within a predetermined estimated range
Time for this stage: Varies a lot based on availability of client staff for discovery, but typically takes between 15 and 30% of total project time
Output of this Stage: A system design, system specification, project cost, project schedule, future project roadmap items, and calculation of return on investment
The hardest single part of building a software system is deciding precisely what to build. It’s also the most important. There is no
cost savings greater for a system feature than the cost forgone by not building something you don’t need, and no greater business
advantage gained than the ability to do things competitors simply can’t do.
Steve Ballmer, CEO of Microsoft after Bill Gates, laughed at the iPhone
when it came out. Not only could Microsoft’s leadership not think of building something as game
changing as the iPhone, even when shown one already built, they still didn’t get it. Microsoft’s failure wasn’t that their
engineers couldn’t build an iPhone if given the designs (they could have!) Their failure was in not even being able
to think of creating such a device to begin with.
In the "Determine what to build" stage (parts of which are also sometimes called "project discovery", "system specification and design",
or "specification and architectural development") we uncover what your organization wants to achieve, and then partner with you to come up with a design for a system to achieve it.
One of the first questions we ask new clients is "What would you like to build?" But that’s not actually what we need to know. We need to
know "What would you like to achieve?" and there’s a strong distinction.
“A great lathe operator commands several times the wage of an average lathe operator,
but a great writer of software code is worth 10,000 times the price of an average software writer.”
Founder of Microsoft and the Bill & Melinda Gates Foundation
Our clients tend to be innovators. After all, they are hiring developers to create new solutions, rather than
muddling through doing things the old way. Therefore, clients often have a business problem, let's call it "A",
and then they think to themselves "How can I solve 'A'?" They then think up a solution to A — let's call it 'B'. Then they call us and say "Can you build us 'B'?" To which we invariably respond, "Well, yes, we could — but that's probably not what you want. Let's talk about 'A'." We say
this because, given a business problem, Mighty Ant DataWorks is one of the best in the world at coming up with a
technology solution. We ask "What would you like us to build?" just to shed light on what you want to achieve, and then we delve deeper.
We then create systems that solve problems better than our clients ever could have imagined.
For example, the founder of FamilyInfoShare, a startup centered on capturing a great variety of financial and other information
for people to share with their family members, estate planners, and others,
contacted us about creating a software system that would use a friendly, comprehensive online interview to gather information (sort of like the product TurboTax does to
interview you to help you prepare your taxes.) We gave this founder a ballpark estimate on costs in his initial free consultation call, but as we had a 3 month wait at
the time before we could start on new projects, he explored working with another team instead. The other team gave him a very similar cost estimate as we had, and
worked out that they couldn’t build the full product on his budget, but could get him started by building the first 20 screens of the interview which could then
be expanded later. Things ran a bit long on getting started on his project, and he checked back with us when we were available, and ended up going with us to determine
what to build. We decided that what he needed wasn’t interview screens for his extensive interview process, what he needed was a software system to let him
build his own friendly and easy to use financial interviews. We built him a system to build his interviews, and he ended up building
over 300 screens of the system for the same price another group quoted him to build 20. We brought two big advantages to the project over the competing group: we
uncovered what he actually needed to do to accomplish his goals, and we had (the somewhat rare) developers who were experienced in building such systems.
Software specification and requirements gathering consists of working with your staff to see what they need to do (not necessarily what they are currently doing),
and determining how a new system can let your staff do it much better. We interview users, review existing reports, learn existing systems and procedures,
uncover why things are done the way they are now, then, with business goals, budget, and other constraints defined by the client,
come up with new solutions to old problems to get work done much more quickly, with fewer errors, and less effort.
The specification work product for a simple job might be a couple of pages of written description exactly outlining
the business problem to be solved, and the requirements for the solution that will be provided. A specification
for a larger job might be 80 pages of features and system details, spelling out the various trade-offs, including diagrams, sample files, mock-ups, and more.
Design problems, missing features, and system flaws are 50 to 100 times cheaper to fix at the specification
phase of the project (where you are exactly describing the future system, not yet constructing it) for
the same reason that it's easy to erase and move the position of doors on a building blueprint than to
later move the actual doors on a 12 story building. We figure out what we will build before we build it,
more so than other developers — both because we can (as we have the required discipline, communication skills,
and a mature development methodology), and also because it saves our clients a great deal of time and a great deal of money.
2. System Construction
Who you’ll work with: Development Lead, Developers
Cost and Billing Type: Typically between 70 and 80% of total project cost. Usually billed either flat fee or weekly in a predetermined estimated range.
Time for this stage: Typically between 50 and 70% of total project time
Output of this Stage: Visible system milestones then a working system
Most of a software project’s budget and most of its time are spent on actual system construction — the task of actually building the software. During this phase
you receive regular updates and view visible system milestones as the system is completed. When new questions come up during system construction your
development lead will get your input so the system can be matched to your business needs.
Great software is created by great developers.
As mentioned earlier, the cycle of invention is repeated several times during most projects. We repeatedly go through the cycle
1. determine what to build → 2. system construction → 3. testing → 4. deploy to users → 1. back to determine what to build.
Each time through the cycle, new functionality is deployed to users, the business gains the value of its investment, we learn better what to add to the next development
cycle, and the process repeats. So the initial plan put together in the very first "Determine What to Build" cycle is a high level plan, mapping out the relative
size of the various development cycles of design, build, test, deploy, then picking which task to do first. Before starting system construction we figure
out what your business needs to achieve in the big picture, then determine which modules / smaller development cycles will get us where we want to go, then
specify the plans for just the first build, test, deploy cycle in great detail (leaving the other cycles in broad outline.) We then execute, build the
new first module or set of functionality for the system, get users using it, and then everyone will have even more ideas on what and how to do the next
development cycle after they have learned from the first one.
For example, with our client ForensisGroup we built (and are still adding onto and maintaining) a business automation system that radically increases what
their entire company can do. When we first started work with ForensisGroup they had an internally built database system that they had been using for over
15 years. It did relatively few things, had a very cluttered interface with all sorts of odd features (many no longer used), was unintuitive, and inefficient.
But it was also what the entire
company had solely used for 15 years! Everybody was used to it. Everybody thought in terms of how the old system did things — with procedures based
on limitations it brought. Henry Ford said "If I asked people what they wanted, they would have said 'faster horses.'" If we asked ForensisGroup what
they wanted, they would have said "To do what this system does but much better."
"It’s better to wait for a productive programmer to become available than it is to wait for the first available programmer to become productive."
and Rapid Development
Working with ForensisGroup we mapped out what they wanted to achieve, where they wanted to be long term, what tasks would be the biggest pay-off to automate first,
and then picked our first module/project: replacing their old database system. So we examined everything that the old system did, made sure the new system
would replace that functionality (with vastly more capabilities), and then also added in all sorts of standard workgroup automation features that come with
any of our typical systems (client activity tracking, automatic mass email systems, automatic email template systems to generate emails from a database
and automatically merge in customer information, reporting, query, export, and other tools, etc.) We designed this system, built it, tested it out with
them, then deployed it to their users. The users saw truly dramatic improvements in capabilities and efficiencies. They also had to learn how to do things
in new ways. Some of what ForensisGroup staff used to do every day were things that were the core mission of the company — talking with customers to match
them up with great legal experts, working with experts that ForensisGroup matches on necessary client issues and details. But many other tasks the company’s
teams did were just repetitive work required because of limitations of the old system. The teams learned new procedures and tools to do their jobs in new
ways, and productivity — and ideas for future improvement — both continued to increase.
After we replaced ForensisGroup’s original old system, and the team was fully up to speed on using it, and excited about adding additional improvements, we next
automated dozens of their operations reports. These reports were previously painstakingly compiled by hand each month and also at the end of each year. We looked at all
of these complex reports, designed a system to automate them, and when the operations reports project was done all the work of compiling those reports disappeared
forever. They could now run any report, at any time. They started using the reports more often as they were so much easier to run. They now had automatic
reporting showing operations numbers, automatic pie charts, and automatic line charts with interactive date ranges — something they hadn’t even imagined
when creating the reports manually.
After the operations reports project, we helped ForensisGroup with a project to help their company website (which hadn’t been created by Mighty Ant.) We managed to triple the
speed of their website by instituting a proper caching architecture dropping page lead times from over 6 seconds to under 2 seconds. We also pointed them toward a
variety of other necessary improvements (and encouraged them to seek a new team as their original website construction team wasn’t even average — they
were below average and that turned out to have costly ramifications.)
After that we automated sending thousands of billing notices they send out each week. This used to be done by hand, but now happens automatically, with each notice
automatically customized to its recipient’s situation and details. As we write, we’re now working on a new system to radically change how the entire organization
uses email as we’ve done for other clients, automatically ingesting hundreds of thousands of emails and attachments and linking them automatically to clients,
client activity, and their case files. Later down the road we have discussed projects to automate their billing system, to integrate more closely and automatically
with Docusign, and other projects.
Each of these projects went through a determine what to build, build, test, and deploy cycle. Each time
we learned more about how better to do things for the next iteration.
We build large software systems in stages, with each stage delivering a working and valuable system.
Users get new insight into what is possible once they start using a system, so we work to get
to system use as quickly as possible. Experience with the first working parts of a large system gives
users ideas to refine future portions, and building a project in stages makes progress visible, concrete,
and more immediately useful.
Who you’ll work with: Development Lead
Cost and Billing Type: Varies. Typically between 2% and 6% of project cost. Part of a project’s flat fee or weekly billing.
Time for this stage: Varies a lot by project type. Might be anywhere from 2% to 20% of total project time
Output of this Stage: Production ready system, users more educated on upcoming changes
Mighty Ant tests systems in many ways and at all stages of development. During design and specification we test out ideas with user
feedback and system mock-ups, during system construction we use automated unit and integration testing, during deployment
we do tests to confirm customer data migration integrity. But the separate "Testing" stage of development is the part of testing
that takes place between construction of the system and deployment of it to users where users test out a system to confirm that
it meets the business goals, and get a chance to start getting familiar with it before it is deployed to users.
With a mobile application this sort of testing is done by sending the mobile app to users who can test it out to confirm that all is
well before it is deployed to one of the public app stores. With a web application the testing might be done on not-yet-public
web pages that staff can access to test out the system, or, for larger changes,
testing is done by users on a separate testing server entirely. For desktop applications, testing usually consists of bringing up the
new application to test side by side with the old application still being used. Staff can test out the new system without being
concerned about breaking anything or messing up any business data, and can try out new procedures in the new system while still having
the old production system completely available to do their ongoing work.
Often when users are testing a system it will finally start to sink in how remarkably easier and more automated their jobs are
about to get, and they’ll start to come up with dozens of new ideas for further automation. People already believed the
new system or application would be great (otherwise they wouldn’t have paid to build it!), but once they start to physically
see it in action, this information sinks in a new way. As all of these new ideas come up for future additions and improvements
we record them to put into the next "determine what to build" project phase (as we don’t want to delay too much at this point
because we’re about to get to "deploy to users" where the business starts reaping the rewards of its investment.
Once the users confirm that the system does what we set out to do, then we move on to deployment.
We like what Steve McConnell, famous
"Testing by itself does not improve software quality. Test results are an indicator
of quality, but in and of themselves, they don’t improve it. Trying to improve software
quality by increasing the amount of testing is like trying to lose weight by weighing
yourself more often. What you eat before you step onto the scale determines how much
you will weigh, and the software development techniques you use determine how many
errors testing will find. If you want to lose weight, don’t buy a new scale; change
your diet. If you want to improve your software, don’t test more; develop better."
4. Deploy to Users
Who you’ll work with: Development Lead, Trainer
Cost and Billing Type: Varies. Typically between 5% and 20% of project cost. Part of a project’s flat fee or weekly billing.
Time for this stage: Varies by project type. Might be anywhere from 2% to 15% of total project time
Output of this Stage: New system fully in place, users trained in its use, more work done in less time, new organization capabilities and competitive advantages
and using it
We build software so we can use it. "Deploy to Users" is the process of putting the software into use. For a new mobile application, it may just consist
of submitting it for publication to the various app stores. For a major business system, deployment consists of user training (both on-site and remote),
automated data migration to
move business data from the old system to the new, and then very close support for users as they start to use the system daily to do their jobs.
Deployment to users is when the business starts to gain value for its investment. It’s also when users truly start to understand what has been built for
them. A car designer may be able to picture a new car by looking at a dozen detailed blueprints of it. But normal people have to sit in the car and take
it for a drive to get a feel for it. When they do, they start to understand how much better a car is than a very old horse (the feeding is much simpler. No
more daily feedings and cleaning the stall or brushing the horse after it works — you just go to a gas station and fill up the car’s gas tank every couple of weeks.)
We provide training, support, bug fixes, and minor feature additions to help users adapt to the new system. We help users with any questions, and provide necessary documentation for both users and your IT folks that take care of your servers and network.
Maintaining Your Investment for the Long Haul
Who you’ll work with: Development Lead, Developers
Cost and Billing Type: Varies by project type. Typically between 2% and 6% of project cost on an annual basis. Usually payment by maintenance contract.
Time for this stage: Ongoing
Ongoing maintenance keeps your mission critical systems in good health and delivering value to your organization. For different projects ongoing maintenance may include
system hosting, management of automated backups, operating system and security update work, ongoing user support,
and fixes for any glitches that may come up.
Mighty Ant DataWorks offers a variety of maintenance contract types covering everything from basic hosting, to ongoing system management,
security management and incident response, to full application and ongoing user support agreements. None of these are required. You
own the systems we develop for you, and you can support them as you wish. But many clients prefer to have their systems professionally
managed and maintained, so they know they never have to worry. Clients with maintenance contracts also get preference in project scheduling
for system improvements.
Mighty Ant maintains long term relationships with clients. The longest we’ve provided
maintenance for a client is 26 years (we’ve been in business for 29.) We build our work and then suppport it long term to make sure
your investment continues to pay off year after year.
We love making software!
Engineering is the application of scientific principles toward practical ends. If the engineering isn’t practical, it’s bad engineering.
We love making software — making a practical difference in the lives of real people we work with.
And our favorite part of the process is seeing the real business results people get from their new systems.