PLANNING A CUSTOM

SOFTWARE DEVELOPMENT
PROJECT
OVERVIEW

This paper is intended to help decision makers, project managers, and entrepreneurs successfully
plan custom software projects.

The advice offered in this paper is for those doing custom software work. This is different from
installation/rollout of an off-the-shelf product; change management is still important when
deploying a piece of custom software, but the technical hurdles of making something from scratch
or customizing an existing system are far greater than in the case of off-the-shelf software.

UNDERSTANDING BUSINESS VALUE

SOFTWARE AS A MEANS TO AN END

Whether you are working on an internal project within a large company, owning a product for a
small company, or developing something for your own start-up, you must remember that software
does not exist for its own sake; it solves a problem. It may save money, save time, entertain us, or
otherwise improve peoples’ lives, but there should be a clearly identifiable problem that the
software is addressing.

In one sentence in the box below, fill in the problem that the software you are considering will
solve:

CALCULATING BUSINESS VALUE

What is it worth to people for this problem to be solved? Being able to clearly answer this question
will, when combined with other cost considerations and your tolerance for return on investment,
define the upper cost limit of your software project. If you can’t explain the benefits of the project,
you can’t expect people to foot the bill.

At Entrance, we build the benefit side of the equation in a few common-sense ways:

TIME SAVINGS

Number of people performing the task to be automated

x How often the task is performed

 x Average hourly pay for the people that perform the task

x (Time task takes before automation – Time task takes after automation)

= Benefit due to time savings from automation

The numbers above should be over a set period of time. We often use a 3-year window because
that is a reasonable time horizon for the useful life of a software system before rework is needed.
In this case, you would use how often the task is performed over the 3 year period, and the
equation would spit out the savings for that 3 year period.

When showing the value of time savings, people sometimes push back because they claim it’s
unrealistic to assume that productivity gains will turn into cost savings, because they can’t go out
and fire the extra workers.

Our response is that gains can still be realized over time through attrition, or through repurposing
extra workers onto other valuable tasks.

INCREASED REVENUE

When productivity of revenue-generating employees is being increased, the same calculation can
be used as in Time Savings, above.

When the software being developed is a product to be marketed, research should be performed
to get a sense of the number of customers that may be interested in the product, what they would
be willing to pay, the customer acquisition cost at that price point, and how much will be spent
per customer to service and retain them. This is more complexity than we’re going to take on here,
but consider bringing in an expert to assist you if you lack experience with this kind of analysis.

If the software being developed is going to expand on an existing piece of software, as in an

additional module for a Software-as-a-Service (SaaS) product, you must make projections as to
how the new software might affect customer acquisition and retention rates as well as price points.
Will the software bring you to feature parity with a competitor, decreasing your customer churn
rate? Will it give you an edge and make it easier for your sales team to bring in new customers?
All these considerations can be boiled down to a projection of how this investment will affect
revenue over time.

DOCUMENTING VALUE

We recommend that you go beyond a vague notion of business value that exists in your mind
and concretely document your assumptions and conclusions in a business case. This can start as
a document, and the content can be transferred over to a slide deck when you get to the point of
presenting your ideas to others.
Forcing yourself to write everything down will clarify your ideas, make it easier to come back to
them, and expose soft spots in your reasoning.

DETERMINING INITIAL SCOPE

Now that you know the value of solving the problem your software idea addresses, it’s time to
get a handle on the other side of the cost-benefit equation. Of course, you can’t figure out how
much it will cost until you know what “it” is.

APPROACH TO SCOPE PLANNING

At Entrance, we have successfully used a scoping approach that combines Waterfall and Scrum.
Lovingly nicknamed “Scrumerfall”, this approach provides the benefits of having a plan that spans
the entire project with the flexibility of frequent iterations.

The goal of the scoping phase is to end up with a vision for the project, which includes a number
of high-level features. The features are then prioritized, and the highest priority features are
fleshed out further into work items.

Defining the major features up front allows them to be prioritized and it allows our architects to
design a solution that won’t become obsolete by the end of the project. Defining work items for
the highest priority features means our development team can hit the ground running. On the
other hand, waiting to precisely define all work items reduces the amount of wasted work, because
we won’t spend time gathering requirements for work items that are never implemented, or ones
where the requirements change.

CHOOSING A TOOL TO DOCUMENT SCOPE

There are a number of tools to document and manage scope. Our team has used JIRA in the past,
but our tool of choice these days is Microsoft's Visual Studio Team Services, which is the hosted
version of Team Foundation Server.

It allows for both code and work items to be managed through the same service, it has
customizable templates for different development approaches, and it allows for collaboration with
parties from different companies.

Your needs may vary; the important thing is to take the time to assess those needs and ensure
you have a tool that meets them. We’ve seen teams in the past try to wing it, which got them into
trouble, especially when it came to source control/branching and merging of code.

GATHERING REQUIREMENTS

There are a few things to bear in mind when doing your initial requirements gathering work:
Expect this phase to take 3%-8% of the total project time

Holding stakeholder meetings and then documenting findings in a way that is crystal clear for
your dev team is time consuming. There is going to be back and forth to clarify things, additional
prioritization meetings, and conflicting ideas about how the software should behave. Be patient
and invest this time now so you don’t have to rewrite code later.

Include the right people in the room

In an ideal situation, you want people interviewing stakeholders that understand the processes
the software is addressing, know how to interview and document requirements, and know the
technical side of things to steer the group towards requests that won’t break your bank. This
doesn’t necessarily mean three people need to be conducting the interviews, but the people you
do send in should have these skills between them.

Talk to stakeholders and end users

End users are critical to include in this conversation because only they know the truth about what
they really need from the software. Additional stakeholders can include decision makers and
influencers that will be more likely to support your project if they have a hand in the early stages.
Making suggestions and having them listened to is a great way to build a sense of ownership.

PROJECT TEAM, COST, AND SCHEDULE

TYPICAL PROJECT ROLES

Now that you have scope documented at the feature level for the entire project and the work item
level for the beginning of the project, you can get a better idea of the members of the team that
will be needed. Bear in mind that the roles listed below represent skillsets, and a single person
can play multiple roles.

ARCHITECT/TECHNICAL LEAD

This person is responsible for understanding the long-term vision for the project and putting
together a technical design that will support it. The architect is often, but not always, the technical
lead on the project, solving the most difficult problems, coaching the supporting developers, and
auditing code.

DEVELOPER

In this category, we’re including anyone who touches the code. This role might include more
specialized duties like database creation or front-end specialist. On a day-to-day basis, developers
should be taking work items and turning them into working code, assisting each other, making
and hitting estimates (to a reasonable extent), and sharing ideas to improve the product.
PRODUCT OWNER

This person is responsible for prioritizing work throughout the life of the project. In order to do
this, the Product Owner must understand the business value of the work items and features in the
backlog. They maintain communication between the development team and various stakeholders,
keeping stakeholders up to date and relaying requests back to the development team.

BUSINESS ANALYST

Since we are purposefully leaving many work items undefined at the start of the project, business
analysis/requirements gathering is needed throughout the project, until the development is
nearing its end and the full scope of work is defined. It’s the BA’s job to make sure that the items
deemed highest priority by the Product Owner are ready for the development team to take on.
We always encourage developers to ask questions of stakeholders directly, but for more complex
discussions, the BA can help clarify requirements during the sprint.

QUALITY ASSURANCE ANALYST

This person starts work in earnest towards the end of the first iteration (aka sprint). Since the goal
of each sprint is to deliver potentially shippable software, testing is an ongoing endeavor that
takes place alongside development. The QA can also help create automated functional tests. Since
they are deep in the weeds of the product, they should be expected to suggest improvements
throughout the life of the project.

PROJECT MANAGER/SCRUM MASTER

This person is responsible for making sure everyone is following the process, to facilitate
communication between people and groups, to measure progress and keep an eye on the long-
term plan, and to make sure people are performing up to snuff. A good project manager does
much more than just maintain a schedule. They help speed up work by facilitating discussion,
push the group to improve each iteration, use their position at the center of the action to put
events in context for the team, and remind people of the short- and long-term project goals.

OTHER/SPECIALIST

These vary depending on the project, but you may need to bring in someone who is an expert on
a specific technical need, such as distributed computing, cryptography, or offline data sync.

DETERMINING PROJECT ROLES NEEDED

Depending on the size and type of the project, you can eliminate or combine some of these roles.
Technical specialists are often not needed. Developers can act as QAs if the project is small enough
and if process is still being followed. The Product Owner can act as the BA.
Now is the time to record the roles you think will be needed in your project proposal and think
about where you will source these resources. Do you have an internal team with the skills to fill all
of these roles? Will you need to turn to a 3rd party to help out? Will you need to cobble together
a team from several freelancers, or will you go with a company that offers turnkey project teams
with all the roles covered?

COMPARING TYPES OF 3 R D PARTY RESOURCES

Overseas freelancers pose the highest risk in terms of communications and time zone barriers.
They are also not part of a larger organization you can hold to account. On the other hand, they
are the cheapest option, with developers available for hire from $5 - $30 per hour.

Onshore freelancers are more expensive, but you benefit from fewer time zone and
communication barriers. You still are dealing with one person, so you can’t complain to a manager
when they don’t do a great job. You also worry about what happens to your project if they get
sick or go on vacation. Onshore U.S. freelancers typically range from $15 - $100 per hour,
depending on the experience and how specialized their expertise is.

We consider contractors referred by staffing or placement agencies to be roughly equivalent to

freelancers. You have slightly more accountability and the option of trading one resource in for
another, and you pay a premium in the form of a placement fee.

The easiest and quickest route to getting your project done is to work with a firm that maintains
a team of technologists. They will be able to bring people in to fill the different roles, and they
have a defined process in place that everyone is trained to execute. You are paying more for that
speed and productivity, however, with per-hour prices ranging from $100 - $250. This route has
the added benefit of a larger organization backing the team up, meaning resources have support
if they run into a problem they can’t solve themselves or if they get sick/go on vacation.

Many firms are combining an onshore presence with an offshore development team in an attempt
to provide results you would expect from an exclusively onshore team at a lower cost. If the firm
can handle coordination between onshore and offshore resources, this can save money at the
expense of not being able to sit down with your developers. Beware of companies that quote as
if they are using onshore, high-cost, high-productivity resources and instead flip your work over
to an offshore dev team.

ESTIMATING THE WORK

When it comes to estimation, there are three things to keep in mind:

Everyone is terrible at it

Research has shown that people are bad at estimating, especially when hypothesizing about the
extremes of a guess. Professionals working in the software space should be able to get pretty
close if they understand the scope of work and are familiar with the technology to be used. Still,
it’s a good idea to build in a decent contingency into our budget estimates (somewhere around
20% is a good rule of thumb for a build phase).

Let actual performance validate your estimates

Have the project team estimate in “Story Points”, and then calculate the number of story points
the team finishes each sprint. A couple of sprints in, you’ll start to get an idea of the actual velocity
of the team, rather than being forced to rely on estimates.

What’s important is for the team to be consistent with what a story point represents. It can be
helpful to calibrate the team at the beginning of estimating sessions by reminding them of some
past work items and what was estimated for those.

Of course, you need to be able to budget in hours and dollars, not just in story points. It’s perfectly
fine to take a guess as to how many hours each story point equals, just realize that this assumption
will definitely be revised as the project goes on.

Have the members of the project do the estimating

This has two major benefits. First, it creates a sense of accountability in the team to try to hit their
estimates. If someone else estimated a feature and they didn’t have a say in it, they will have a
built in excuse when they blow the budget.

This excuse is not unreasonable. The people doing the work will have the best idea of how long it
will take them to do it. Therefore, the second benefit of having the members of the project
estimate is it will produce more accurate estimates.

DECIDING ON COST AND SCHEDULE

Once you have estimates for the number of hours the work items will take, you can work with
your architect/technical lead to plan how those hours might be divvyed up among the resources.
We will typically assume 10% - 20% of the developer’s estimates will be needed on QA, same for
BA, and slightly less for Project Management.

At this point, you can use a tool like Microsoft Project to schedule out resources based on their
availability. This will give you a provisional schedule to add to your project proposal.

You can also document cost at this point. It’s wise to document not only the raw-dollar costs of
3rd party resources but also the time that will be needed from internal resources. You should also
be able to work with your architect/technical lead to get an idea of the hardware costs and
hardware/software licensing costs.

CONCLUSION

If you’ve arrived at this point, you have documented and/or prepared a presentation detailing the
problem you are trying to solve, the benefits of solving this problem, the features and high-level
plan for your software solution, the technical team needed to get it done, the cost of the effort,
and the schedule to release.

I wish I can say the easy part is done, but you still have to get funded and then deliver the project!
The good news is thorough planning has eliminated much of the uncertainty, and you’re in a great
spot to succeed.