the parknpayapp business plan - web.stanford.edukunz/chalmers/s3_2013_1.pdf · 1. value proposition...
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. ���
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���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���