framing and scoping your project · 2019. 9. 11. · features bucket—otherwise known as the mvp...
TRANSCRIPT
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.”
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