FRAMING AND SCOPING YOURPROJECTIDENTIFY YOUR FEATURESIDENTIFY YOUR BUDGET

THE ULTIMATE GUIDE TO HIRINGA SOFTWARE DEVELOPMENT COMPANY

VOLUME

2

FRAMING AND SCOPING

THE PROJECT

How do I scope a project?

Where am I in the life cycle?

What details do I need to know?

Do I need finished designs?

Does the project have product requirements?

Does a current software system already exist?

What tools should I use?

These are important questions to answer. The goal of answering them is to

pinpoint where you are in the software development life cycle (SDLC).

SOME QUESTIONS TO

CONSIDER

FRAMING AND

SCOPING

Scoping a project is paramount when

selecting a software development

company. The time spent defining

what you want will help you in the

long run. The more prep work you put

in up-front, the more accurate the

quote and expectations will be from

the software development company.

This volume will explain the Software

Development Life Cycle so you can

understand your current position in the

process. By understanding your

current situation, you’ll be equipped to

make more informed decisions moving

forward.

03

Going f rom fea tu re l i s t to fina l p roduc t

Framing and scoping your project

01

Modern So f t ware Deve lopmen t

L i f e Cyc le

TA

B L

E

O F

C

O N

T E

N T

S

02

Budge t Backwards ve rsus Fea tu re For ward

0 4

How much i s i t go ing to cos t?

MODERN SOFTWARE

DEVELOPMENT LIFE CYCLE

MO

DE

RN

SD

LC

AG

ILE

TR

AD

ITIO

NA

L S

DLC

(WA

TE

RF

AL

L)

1

Traditional SDLC (Waterfall)

Traditional software development tends to have rigid

principles and a more defined process than modern software

development. The traditional way to develop software was to

completely define a product at the beginning, and then

design and develop directly from the specifications.

This is a traditional SDLC: Requirements → design →

development → testing → maintenance.

The waterfall methodology follows this specific order without

iterations. The phases can be considered fixed meanwhile the

modern software development cycle is more flexible in how it

handles change throughout the development cycle.

Throughout a waterfall software development process, there

is little room for pivoting based on new information.

The rigidity of the process doesn’t lend itself to emerging

technologies and modern software paradigms. Things change

too quickly nowadays to completely define a product up-

front.TR

AD

ITIO

NA

L S

DL

C

2

The Modern SDLC (Agile)

The modern software development life cycle follows a similar

process to that of the waterfall methodology, but it leaves

room to quickly pivot based on changing priorities. Many

refer to this as the agile methodology.

Many companies say they operate with an agile process,

but they actually run some sort of agile-hybrid, and use the

word agile to suggest a high degree of communication and

some of the agile principles. These principles still largely

define the intent behind the modern SDLC.

It’s a continuously iterative process that starts with strategy,

has release cycles along the way, and doesn’t technically

end, even once you’ve launched your application. The idea

behind the Modern SDLC is to ship a product as quickly as

possible and to communicate transparently along the way.MO

DE

RN

SD

LC

3

9

“The old way moved slower due to the

requirement to define everything up-front.

That, and the size of software projects used

to be larger, with more required in the first

version and very little room for change

throughout the project. Technology moves

too fast for rigid process now.”

–Bill Lukefahr, CIO

BUDGET BACKWARDS VS

FEATURE FORWARD

BU

DG

ET

/T

IME

LIN

E B

AC

KW

AR

DS

FE

AT

UR

E F

OR

WA

RD

5

BUDGET BACKWARDS

VS FEATURE FORWARD

Budget, scope, and timeline are the

three variables in every software

project. From this, we have two

primary types of projects that define

the lifecycle of a product. Most

projects meet in the middle between

these two approaches, but it’s

important to identify which variable is

known and the highest priority in order

to complete the rest of the equation.

6

Budget/Timeline Backwards:

These projects have a max budget or set deadline and

the project team must work backwards to see what can

actually be completed given the allotted time and

budget. These projects usually require you to sacrifice

features or the quality of work in order to come in under

budget and within the timeline.

BU

DG

ET

/T

IME

LIN

E

Feature Forward

These projects are focused on the scope and business

objectives. The software development company will

work forwards to determine an appropriate timeline and

budget based on the scope of work. This approach is

definitely more costly, but you’re app will have

everything you need and more.

FE

AT

UR

E F

OR

WA

RD

8

9

“Budget backwards is similar to walking

into a car dealership knowing the max I

can spend. Sometimes I want a Tesla

Model S, but I only have enough money

for a Model 3. Guess what? I’m going to

end up with a Model 3, and that’s not

Tesla’s fault.”

– Mike McDonnell, Group VP

9

GOING FROM FEATURE LIST

TO FINAL PRODUCT

ST

RA

TE

GY

FE

AT

UR

E L

IST

DE

SIG

N

TE

CH

NIC

AL

RE

QU

IRE

ME

NT

S

10

Software Strategy (“Discovery”)

If the product is undefined, a Discovery phase is the best

place to start.

The time it takes to complete the discovery phase depends on

a number of factors, many of which may deal with your firm’s

organization and approval process.

A product strategy is the why behind your software. To help

define your product strategy answer these questions:

Why build the software?

What is the purpose of the application?

Who is going to use the software?

Walk through a day in the life of one of the users—how does

this software help?

What industry is it competing in?

Who are the competitors?

What platforms and/or mediums are you building for?

ST

RA

TE

GY

11

9

“It really doesn’t matter what you plan to

do if you don’t know who is going to use

your product. You need a target to design

for, and ‘everybody’ isn’t a good answer”

– Jeff Vaccaro, Sr. Project Engineer

Prioritized Feature List

After landing on a software strategy—which includes user

types—the next step is to create a prioritized feature list. Write

out the must-have features of your software, in the order of

importance. Focus on the details that pertain to the user.

Feature lists need to have enough detail to guide design and

establish technical requirements. If your feature list is vague, it

increases the risk of scope creep. Most, if not all, features

need to be discovered during the design phase.

If you don’t know where to start, put yourself in your users’

shoes, and think about how they will access and interface

with your application.

Make a bulleted list of every single feature you want in the

application with as much detail as possible.FE

AT

UR

E L

IST

13

Login

As a user, I need to login to the application with Facebook

and email

Logout

As a user, I need the ability to logout of my account

Signup

As a user, I need to create an account

As a user, I need to have social sign-in

Landing Dashboard

As a user, I can see a summary of my team’s activities

As an admin, I can control what each dashboard displays

Social Share

As a user, I need to be able to share my status on social

media

EX

AM

PL

E F

EA

TU

RE

LIS

T

14

Prioritizing the Features

After all of the desired features are listed, you need to

prioritize them. Separate the must-haves from the nice-to-

have. This can be done in buckets.

The first bucket should be a cannot-launch-without-these-

features bucket—otherwise known as the MVP (Minimum

Viable Product).

Henrik Kniberg and Fred Voorhorst have both created

popular visuals for an MVP and depending on the Product

Definition, either visual might suffice. The idea is to simplify

the product down to the minimum acceptable product for

the market, and build it as version one.

Henrik Kniberg: For a loosely defined product—such as

“improve transportation from point A to B”—the first visual

on the next page is illustrating his MVP concept.

Fred Voorhorst: For a more narrowly defined product—such

as “create a car”—the second visual explains his MVP

approach.

PR

IOR

ITIZ

ING

FE

AT

UR

ES

15

16

Annotated Designs with Technical Requirements

After the feature list is determined, the project can move into the

early stages of design.

During this phase a User Experience (UX) Designer uses the

prioritized feature list to create workflow diagrams. The designer

should make sure that the workflow for every feature prioritizes

usability and takes into account recognized design patterns and

mental models. The workflows are then consolidated into a low

fidelity wireframe that is testable and promotes fast iterations.

The full low-fidelity wireframe will be reviewed and validated

against the plans for any future content / feature development.

At this phase, a Technical Lead should work with the User

Experience Lead to provide input and options from a coding and

timeline perspective.

AN

NO

TA

TE

D

DE

SIG

NS

17

Information Architecture

IA is usually referred to as the backbone of any site or

application. It can be extremely helpful and often necessary

to create.

IA is more frequently required in web applications than

mobile applications. It outlines very specifically how the

application may flow or what information will be on each

page.

A key component of the information architecture is the

appearance, accessibility, and presentation of information. It

is critical to create a design that is scalable for new and

anticipated growth of information, products, and services.

INF

OR

MA

TIO

N

AR

CH

ITE

CT

UR

E

18

User Flow Diagram

Similar to an IA, a user flow diagram is a screen by screen

outline that can be used to validate the user workflow. Before

you start designing or developing anything, you can ensure you

are creating a smooth user experience from beginning to end. It

is often used to determine navigation structure for mobile

applications.

US

ER

FL

OW

DIA

GR

AM

19

Low Fidelity (Wireframes)

This is the most exhaustive part of the design process, which

centers on creating complete user flows based on the

approved and prioritized feature list. In this phase you should

move quickly and test often with lightweight prototypes of key

interactions. This is an iterative process based on feedback,

testing and edits, typically with bi-weekly reviews of

deliverables with the stakeholder team.

Low-fidelity wireframes are incomplete designs that provide

an outline of the product. They are meant to highlight the core

concepts and functionality of the app, without the UI

aesthetics.

These designs explain the flow of the software features from a

user perspective. They can be drawn on a whiteboard or built

using a design software platform like Sketch.

Above is an example of a hand drawn wireframe. As you can

tell, it’s very low fidelity, but it helps establish features and

flow.

LO

W F

IDE

LIT

Y

20

WIREFRAME

EXAMPLE

Here is is an example of a wireframe created in Sketch. It doesn’t always have to

have this much detail, but what you see is still not the final design.

21

High Fidelity (Final Comps)

As wireframes, testing and feedback are completed, the

process moves into final visual design comps to set

guidelines for final development. Now perfect the layouts

created in wireframes and ensure everything is pixel perfect

before moving into development. Once development

begins it will become harder to pivot without incurring

additional cost.

HIG

H F

IDE

LIT

Y

22

Technical Requirements

From a technical perspective, the software development team

should determine the appropriate architectural patterns that

best support your needs. They should establish the

foundations of your app, including the infrastructure to

support continuous testing and delivery throughout the

development process. The team should create physical and

logical architecture diagrams and define the key business

objects. The team should work collaboratively with your team

to determine an optimal set of API contracts, based on the

design requirements.

TE

CH

NIC

AL

RE

QU

IRE

ME

NT

S

23

Development Schedule (Sprint Plan)

A development schedule (or sprint plan) consists of both a

timeline and an engineering team. First, estimate the total

amount of hours it will take to complete the project. Once you

have a total, that number can be broken down into sprints

with assigned features.

Each sprint iteration begins with a grooming session, where

stories are analyzed, improved if necessary, and divided up

into tasks. Sprints are usually planned in one or two-week

increments. Take the prioritized feature list and assign each

feature to a sprint.

The more defined the designs are, the lower the risk.

However, the project still hinges on how skilled a

development team is at building software.

Note* Estimates are difficult and can vary significantly based

on your project requirements. Once design is finalized, a

team should have a better understnading of the development

effort.

TE

CH

NIC

AL

RE

QU

IRE

ME

NT

S

24

Launch

All of your hard work is paying off and you are ready for

your first release, usually it’s the MVP (minimum viable

product). This is an exciting milestone and accomplishment

in the software development process.

Things to think about during launch:

Have you load tested the application?

How many users are you targeting?

Do you have developers on queue to fix bugs?

Is customer support set up for this software?

What are the next features to add to the app?LA

UN

CH

25

Feature Improvement

After the first release of the product, the product team should

focus on the next set of prioritized features.

FE

AT

UR

E

IMP

RO

VE

ME

NT

26

HOW MUCH DOES IT COST TO

BUILD AN APP?

TH

E M

AG

IC T

RIA

NG

LE

TH

E V

AR

IAB

LE

S

27

9

“Apps built by the largest app companies, the

“big boys,” likely cost anywhere between

$500,000 to $1,000,000. Apps built by

agencies onshore software development

companies cost anywhere between$150,000

to $450,000.”

– Google

28

The Magic Triangle

It is difficult for an agency to estimate the cost of a software

project if you don’t have a basic outline, which is why it is

important to define the scope of your project.

Picture asking how much it would cost to build a custom home

without knowing how many bedrooms you need. How about

bathrooms? One story or two? Is it a remodel or a ground up

build?

As you already know, understanding your project is the key.

After nailing down a few important details, choosing which

type of firm you should hire is much easier.

When talking about cost, a helpful diagram is the ‘Magic

Triangle’. The theory suggests you cannot expand one side of

the triangle without affecting the other sides.

Time, cost, and scope are not mutually exclusive.

TH

E M

AG

IC

TR

IAN

GL

E

29

SOFTWARE PROJECT

VARIABLES

What is the budget? Is it realistic for the scope you want?

A professionally built app will usually take around four to six months and

cost somewhere between $150,000-$550,000 depending on

complexity.

Who are the stakeholders?

The more people involved in making decisions, the longer the timeline.

What are the technical capabilities of your team?

A clear definition of who does what is necessary to get everyone on the

same page.

What is the target timeline?

Four to six months is a reasonable estimate for the first version of a mobile

app.

Do you need designs?

If yes, a full service partner is best. Find an agency that can take your

project from idea to strategy to design and development. They’ll know

your product best!

Variables change the price. Understand the variables and you will be

much less surprised when a quote or timeline changes.

30

How will you communicate?

Where do you and your team fit into the development

process – daily, weekly, monthly updates?

Are there any government requirements?

This can impact the timeline and project requirements. Add

three to five months to your projected timeline.

When is the code delivered and how?

This is often tied to payment terms and project milestones.

VA

RIA

BL

ES

31