the parknpayapp business plan - web.stanford.edukunz/chalmers/s3_2013_1.pdf · 1. value proposition...

29
The ParknPayApp Business Plan Submission-3 Anna Forshufvud Therese Tellstedt Camilla Vachet Viktor Widerberg

Upload: doanthuy

Post on 30-Apr-2019

214 views

Category:

Documents


0 download

TRANSCRIPT

The ParknPayApp������

Business Plan���Submission-3���

Anna Forshufvud���Therese Tellstedt���Camilla Vachet���

Viktor Widerberg���

Table of content���1.  Value Proposition���2.  Financial projections ���3.  Development Plan Summary ���

a. POP���b. Background���c. Deliverables���d. Metrics���d. BIM���

4.  Prototype development���5.  SimVision���

a. Organization Structure Baseline���b. Organization - Functional intent and Design���c. Process – Functional Intent and Model ���d. Design Versions���

6.  Case analysis ��� a. Executive Dashboard infromation��� b. Gant Comparaison��� c. Project Resource utilization��� d. Work Breakdown ��� e. Process quality risk ���

7.  Checklist���8.  ORID analysis���

1. Value Proposition

congestion due to drivers looking for parking

ParknPay!

20 unused capacity. SF Council missing out on revenue stream

30 % min/day spent on looking for parking spots

40 %

ParknPayApp finds the perfect parking spot in no time

Society: Reduced environmental impact

Drivers: Saves time & money

Parking providers: Increased paid occupancy

Important problems:

Benefits:

0

50 000

100 000

150 000

200 000

2013 2014 2015 1016

2. Financial projections

Numbers of App-user

−225 000

0

225 000

450 000

675 000

900 000

2013 2014 2015 2016

Projects revenue

Costs of sales and operation

Gross Margin

Net Income

−450 000

−225 000

0

225 000

450 000

675 000

900 000

Q3 Q4 Q1* Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4

NPV Break Even: Dec 2014

2013 2014 2015 2016

2. Financial projectionsWith an initial investment of $200,000, an investor can expect to get paid back in Q3 of 2015. ���Further dividends will be distributed after that. ���

3. Development Plan Summary

Project Management

Product Development

Marketing & Sales

2013 2014 2015

Design/ Develop

Internal prototype

Internal milestone

Launch

Beta version

Product launch

Design of new features

Pre-planning

SF Council contract

Founding secured

Set budget

Beta version

Add-on features

Recruitment

Planning for new features

Testing Design/ Develop

Testing

Design/ Develop

Events

Partner eventSocial media-launch-

campaign

ParknPay!

Create a user group

Instagram campaign - “How good your life

has become with ParknPay”

SF council campaign

Users: 55,000P-providers: 1

Expansion in 2015 to other big cities in USA

Set budget

Risk assesment

a. POP-model���

•  Level  B   Product:  App   Organiza7on   Process  

Func7on   Pay  -­‐    On  mobile,  Connec.on  to  bank  account  Map  -­‐  Google  map,  Find  free  spots,  Localiza.on    Refill  -­‐  Refill  func.on,  Real  .me  update,  Reminder  

PM  –  manage  project,  manage  team  Designer  –  User  interface,  content  Developer  -­‐  Develop  beta  version,  develop  product  Tester  -­‐  Find  bugs,  customer  sa.sfac.on        

Project  Management  –  Manage  project  and  external  partners  Design  -­‐  Interface  understanding  Develop  App  -­‐  Follow  specifica.ons,  collaborate  with  external  partners  (SF  council),  integrate  contractor’s  products  (Google  maps,  PayPal)  Test  -­‐  Create  a  test  group,  understand  test  data    

Design   •  Design  an  easy-­‐to-­‐use  interface  with  3  features  

•  Develop  the  product  on  5  applica.on  plaQorms  

•  Color  scheme  user  friendly  for  color  blinds  

See  Product  Sketches  on  next  page  -­‐>  

A  team  of  7  employees   PM  –  Schedule,  plan,  manage  mee.ngs  Design  -­‐  Set  specifica.ons,  Design  user  interface,  design  func.ons  Develop  –  develop  codes,  integrate  contractor’s  products,  develop  product  Test  –  Internal  tes.ng,  Beta  tes.ng,  Alpha  tes.ng          

Behavior   •  Widely  access  to  the  product  through  several  applica.on  plaQorms  

•  Reduce  conges.on  in  the  city  •  Reduce  .me  and  money  for  users  •  Easier  monitoring  of  paying  users  for  

clients  

 

•  Reduced  person  backlog  •  Less  than  20  rework  •  Reduced  latency  •  Increased  efficiency  •  Good  communica.on  

•  Stay  within  budget    •  Finish  on  .me    •  No  breakdown    •  Schedule  •  A  product  that  fulfills  customer  

requirements  •  Good  collabora.on  with  external  par.es  

Project  Manager  

Designer(2)   Developer(2)   Tester(2)  

b. Background  Comment: ���We are currently two weeks into the project, that is in the conceptual/design phase.���Explicit model has been completed with specifications, sketches, etc. ���Next ICE session will be concept design. ������ Background  

Your  name   Anna  Forshufvud,  Therese  Tellstedt,  Camilla  Vachét  and  Viktor  Widerberg  Your  organiza.on   ParknPayApp                          Date  (dd/mm/yyyy)   2013-­‐07-­‐11                          Project  phases  that  use  VDC   Concept/  criteria  design   Concept  design   Design  Development   Detailed  design/  shop  drawings              Current  project  phase   Design  Development                          What  type  project  is  this:     Other                          

Why  does  (or  do  you  propose)  the  project  use  VDC?  

Visualize  the  predicted  work,  intergrate  all  teams  and  deligate  tasks  to  decrease  risk      How  will  VDC  assist?   Find  the  cricical  path  and  make  the  team  aware  of  and  understand  the  risks  of  the  project    VDC  methods  you  use   Metrics   ICE                      How  big  is  it  (area)       units:       SF  Inner  city              How  big  is  it  (height)       units:       Everyone  that  has  a  car  and  visit  the  city  will  use  it  Budgeted  cost       units:       $15000  Scheduled  dura.on  (months)   10  weeks          

Personal activities Comment - certification requirements:

Principal respons-ibility Contribute to team Reviewed

Five explicit, quantitative and measurable output objectives for your project, including at least one each that relate to product, organization and process

Specify functional intent

Product (3D) model no   yes   some  

Organization yes   no   yes  Process yes   no   yes  Explicitly model

Create or contribute to one project model, which might be a 3D BIM, organization or process

Product (3D) some   yes   yes  Organization yes       yes  Process yes       yes  Analysis: predict, measure status Two performance predictions and five measured process

performance metrics Product (3D) some   yes   some  Organization yes       some  Process some   yes   some  

Use VDC methods in management yes

Explain management implications of measured performance metrics wrt explicit objectives

c. Deliverables  

Comment:��� 50% of planned deliverables have been met. At this stage of the project no building has been completed since we are currently seeking funds to complete our product and launch it on the SF market. ���The due dates conform to the predicted schedule (see Gantt Scheme) ������

Planned  deliverables   Deliverable  format   Responsible  team,  individuals   Receiving  team   Due  date   Due  date  met  

(Yes/No)?   Expected  LOD  

Design   Sketch   Design  team   Programer   25-­‐jul   Yes   A  

Specifica.on   Excel   Design  team   Programer   20-­‐jul  Yes  

A  Schedule  of  assets  to  manage   Excel   Project  manager   Everybody   20-­‐jul  

Yes  A  

Build  =>  Beta  version   U.I   Programer   Test  Team   21-­‐okt   No   A  

Test  result   Excel  with  improvments  Test  Team  and  Customer  rela.on   Project  manager   01-­‐nov  

No  A  

Alpha  version   App  new  version   Programer   Programer   21-­‐jan   No   A  

d. Metrics  Comment: Improvements of managers response time is critical. Better communication rules could be established to ensure relevant questions are addressed to the best suited team member. We could then expect a decrease in latency observed. ������

Name Comment Target value Tolerance: +-∆ How to use in

management Source of data Type [P, O]

Stakeholders who saw data

last week Collection frequency

Objective Weight

Predicted/ measured value

(how you are doing)

Assesed status

Quality: POE satisfaction wrt program (%) Appropriate U.I 100 5 Guide explaning

how to use Client

assessment P All on team Weekly 50 97 3

Cost conformance to plan (item actual - predicted/predicted) 100 10 Plan next job Project team

design review P PM only Weekly 30 90 3

Schedule conformance to plan (%) 100 5 Plan next job Client

assessment O All on team Major milestones 10 90 2

Team preparation: Fraction of participants saying that other team members came prepared to meeting (%)

100 10 Meeting improvements

Periodic project stakeholder

survey P All on team Turnover time 5 80 2

Latency: % responses received <= 1 day

From manager to team 100 5

Improve communication and speed and bring down the backlog for the manager

Periodic project progress report P Subteam only Weekly 15 80 1

Field RFIs (count) 0 3 Set weekly U.I specifications

Periodic project progress report P All on team Weekly 10 0 3

Fraction of prefab assemblies that take <=1 day to install (%) 60 10

Set U.I weekly specifications, procurement

Project team design review P All on team Weekly 10 60 3

Personal preparation: Faction of participants that say they understood modeled design content and rationale (%)

90 10 Less communication and rework

Periodic project stakeholder

survey P All on team Every session 10 85 3

Team preparation: Fraction of participants saying that other team members came prepared to meeting (%)

90 10 Less communication and rework

Project team design review P All on team Every session 10 85 3

Other (please enter) 13 400 1340 Compare option vs. others

Project team design review P All on team Every session 12 350 3

d. BIM  

BIM  (VDC  project  model)  Content  Specifica7on  

Model  LOD   Scope   Rela7onship   Func7onal  Requirement   Organisa7onal  Form  (  Actor)   Comment  

Organiza7on  

A  

Project  Mangagemnet   internal   Manage  the  project  and  

its  resource   CEO      

Design  easy  UI   internal   Communicate  with  customers   Design  manager      

Programing   internal  

Use  open  source  and  develop  a  good  archetecturing  by  own  coding  

Develop  manager      

Tes.ng     Design  team   Improve  the  beta  version  Test  Team        

B  

User  interface   Design  team  Translate  the  customers  need  to  precise  specifica.ons  

UI  specialist      

Desin  features   Develop  team   reach  the  specifica.on  on  .me   Design  department      

Code  wri.ng     Develop  team   Set  up  a  architecture  that  work  suficent   Develop  Team      

User  experience    Test  Team     Collect  test  data   Develop  Team      

Test  evalua.on  team     Test  Team     Generate  new  

specifica.ons   CR  Manager      

Contract  wri.ng  External     Write  drai  for  contract  for  partners  

Test  evalua.on  team        

Comment: ���At the B level we are using external expertis to assist in the UI Design.���The Customer Relation Manager will ���be responsible for rolling out the different version of the product and making use of the feedback from our users. ���

5. SimVision    a. Organization Structure Baseline���

b. Organization - ���Functional Intent

and Design���

The team: ���It is important that the actors know their responsibilities while being encouraged to communicate with the rest of the team. Plans and milestones are going to be available to all and developed in a transparent manner in order to ease communication and prevent failures.���

Process: ���An iterative process is illustrated below. The developers and designers contribute to the testing functions in the last phases. The manager coordinates the process with the responsible actors to ensure the progress of the project.���

c. Process - ���Functional Intent

and Model���

d. Design Versions ���

d. Design Versions���Case Risks���

Expected results:���Increased project duration and cost���Increased rework���

Observed results:���Same duration as baseline���Increased cost ���

d. Design Versions���Case Primary Tasks���

Expected results:���Longer project duration���Higher process risk ���

Observed results:���One of the lowest risks observed���Project duration shortened���Reduced project cost���Backlog peak at 1.17������

d. Design Versions���Case Reduced Meetings���

Expected results: ���Decreased project duration and cost + increased coordination risks ���

Observed results: ���Overall Coordination risk slight increase but significant decrease of ���coordination risk on certain tasks���

 

6. Case analysis������•  Stay within budget – With the Case – Baseline as our reference. The Case –Risk results in an

increase in costs like expected. The most interesting case to look at when it comes to the impact on the budget is Case – Reduced Meetings. That specific case shows considerable savings when it comes to Total Work Cost. ���

•  Finnish on time – Compared to Case - Baseline, Case – Reduced Meetings has the biggest impact on the duration of the project, with a decreased project time of 18 %. The other studied cases have no major impact on the estimated project duration.���

•  No breakdowns – Since we encountered difficulties when running the models with different functional and product risks we had to set it at at constant level. This could impact the results significantly and will therefore be considered seriously going forward in the project. ���

•  Conformance to Schedule – As shown in the Gantt charts (slide 23), Case – Primary Tasks has the most impact on the schedule, shifting most of the tasks on the critical path to an earlier point in time.���

•  Product quality – The task Developing links is the parameter that is most prone to influence our processes regarding product quality���

���

a. Executive dashboard������

Comment: ������Lowest risk ���Case- Primary Tasks������Highest Risk���Case - Risks���

b. Gantt Comparison������

Baseline vs. Case Primary Tasks��� Baseline vs. Case Reduced Meetings��� Baseline vs. Case Risks���

Most time saved���

Least impact on schedule ���

c. Project resource utilization���

Baseline���

Case Primary Task���

Case Reduced Meetings���

Case – Primary Tasks shows less utilization of ���the resources when the complete duration of ���the project is considered. ���

d. Work Breakdown���Baseline vs. Case Risks���

Case Risk is here shown to result in higher risk when considering work breakdown.���

e. Project Process Quality Risk���Baseline vs. Case Risks���

Case Risk is here shown to result in higher process quality risk all tasks considered���

7. ICE pre-plan Checklist���Problems  and  subtasks   Outcome   Par7cipants     Agenda   Resources  

0.  Project    Management   SMART-­‐Goal  sejng  and  task  assigned  to  the  team  

Designer,  tester  and  developer  

Set  and  review  project  goals   Computer,  room  for  mee.ng  

0.1  Budget     Founding  secured,       PM,  Angels,  SF  council   Secure  development  1  year   Dinner  and  company  visits.  Product  presenta.on  

1.  Simple  U.I   Easy  Features   Designer,  tester  and  developer  

Set  and  review  project  goals   Computer,  room  for  mee7ng  

1.1  Set  specifica.on,  U.I,  plan  revenue  streams    

Clear  direc.ons  and  controllable    

The  team   Design  what  features  to  develop  and  product  specifica.on        

Computer,  room  for  mee.ng  

1.2  Product  lay  out   A  product  for  tes.ng  3  pages  

Designer  and  developer,  SF  council  and  Google  engineers  

(develop  page;  Find,  Pay  and  Check)   Developer,  SF  parking  data  and  Google  map  data  

1.3  Test  lay  out   A  beler  alpha  version  mee.ng  the  needs  

Testers,  developers  and  designer    

Find  bugs  and  improvements   Test  equipment  

2.  Informa7on  flow  about  parking  and  loca7ons  

Par7cipants  with  SF  council  

PM,  SF  and  Google   Generate  a  good  collabora7on  for  future  rela7on.  

Maps,  technology  for  data  transfer  

2.1  Develop  collabora.on  w.  SF  

Future    data  access   SF  council  and  developers,  PM   Drai  contracts,  and  set  up  co-­‐  developments  

Dinner  and  company  visits.  Product  presenta.on  

2.2  Develop  collabora.on  w.  Google  

Get  access  to  plaQorm   Google  engineers,  developers  and  PM  

Drai  contracts,  and  set  up  co-­‐  developments  

Dinner  and  company  visits.  Product  presenta.on  

2.3  Improve  reac.ons  and  collabora.on  

Best  product  on  the  market  

Co-­‐developers  and  development  team  

Benchmark  and  understand  the  customers  need  

Mee.ng  room,  customer  data.    

3.  Customer  payment   Safe  transac7on   PayPal,  PM  and  developer    

Set  up  a  safe  money  transac7on  system  

Technology  for  money  transac7on  

3.1  Buy  product  from  PayPal  

Set  up  a  safe  transac.on   PayPal,  PM   Drai  contract     Mee.ng  room  and  company  visit  

3.2  “looking  safe”   TrusQul  app   Tester,  Developer   Reviews  goals  for  a  trusQul  app   Customer  tes.ng,  free  trials  

•  4 milestones have been analyzed in our checklist���

•  Manager invites all team members to the upcoming meeting ���

⇒  2 hours meeting with 2 ICE sessions���

⇒  Manager send out agenda with attached checklist for efficiency and process reliability���

•  Next task: decide B level deadlines following funding decision. ���

 

���

Goal: Develop an app for parking in San Francisco that is easy to use���

7. ICE pre-plan Checklist���

•  Objectives – What did you see in the class? What factual statements can you make based on the data?���

We observed the power of Simulation when used to test organizational structure, processes and risks associated with a project. We also have a better understanding of the importance of clear presentations to emphasize the substantial content we are presenting.������•  Reflective – What surprised, encouraged or interested you? What concerned or discouraged you?������A few of the ideas and pitches were really good and have a chance to succeed. We were surprised by the fact that some plans were a bit unrealistic, and that not all of the groups had ask themselves the question: would I buy this myself, and if no, who would? Or why not?������•  Interpretive – What sense to you make of what you did as you prepare your proposal?������As we prepared our proposal, our own idea became clearer to us as well. I think even if you don’t need to ask for money, just presenting your plan and expressing it in words and in terms of money could help address important questions in the early phases of the project. ������•  Descriptional – What are our proposed next steps? What is your action plan for next steps?���

If we were to take our app to the next level one of the most important things would be to find with the background and knowledge needed to develop the app. . We will not take the idea further however, but it has been very interesting to get to know the process, and we are certain what we learned will be of value to all of us in the future.���

8. ORID���