Example: evaluation of the project

This is an example for the article “Evaluating incoming projects”.

Evaluating incoming software projects

About the project

It is proposed to automate the process of filling European Accident Report (EAR):

1. the participants fill out an electronic form instead of a paper form;
2. insurance managers verify the data (later most of the data will be checked automatically);
3. after that, the system proceeds cases without any input from the participants (and, what’s important, without any trips to the insurance offices).

Imagine, that you’re in a light vehicle accident. Usually, you fill the papers, then bring them to the insurance office. Sometimes you have to come to the office more than once.

Now, imagine if you can do it all online, from your phone, while sitting in the car. You create a new claim, add another participant by his cell number. You can chat with an insurance manager. You don’t have to wait, and you don’t have to go anywhere.

How it may work:

1. Create a claim (date and location are added automatically, but you can edit it). If somebody is hurt, call the emergency and the police, and we won’t deal with such cases for now.
2. Add another participant by his cell number.
3. Enter your insurance number, so the insurance managers from you companies can connect to the claim. Enter your driver license info.
4. Managers check their databases and choose the short or long process of settlement (usually depends on your accident history).
5. Participants receive access to the further forms and enter more data about the accident.
6. Managers verify data, ask for additional photos and measurements. Then they create a scheme of the accident.
7. Participants confirm accident scheme and add additional info.
8. The system creates ERA based on entered data. The report is accessible via participants’ personal profiles.
9. Managers make a decision, whose fault it is and whose insurance company will pay for it.
10. Participants receive notification and all necessary documents.

How it can be built:

• mobile web app for participants with forms and SMS notifications;
• a desktop app for insurance managers where they can work with lots of claims simultaneously;
• results of each claim are available via a unique link.

Features decomposition

Creation of the claim:

• agreement to use the personal data
• SMS invitation

The forms:

• geolocation (auto + edit)
• file uploads
• local storage and sync

Insurance manager dashboard:

• CRUD managers
• auth by email and password
• claims inbox
• claim edit interface
• drawing accident scheme (positioning vehicles on the map, marking the impact)
• possible integration with API of insurance companies to automatically verification of the entered data

Chat:

• between the participant and his manager, between managers
• web app and desktop push notifications

Claim results:

• PDF generation
• unique link generation for the SMS notification

Estimated pitfalls

1. The primary challenge is to convince people to use this service.
2. Entering a lot of data from the phone can be difficult. We should consider gathering data from documents’ scans.
3. Drawing the scheme of the accident on the phone is also difficult.
4. Integrations with other APIs might be a royal pain.

Milestones

(Let’s suggest, that feedback from each iteration confirms our hypothesis).

First milestone (prototype, one month):

• build a simple mobile app prototype, try it with the real users;
• or (if we want to sell our product to the insurance companies) build a simple managers’ dashboard prototype and emulate the accident participants behavior.

Second milestone (alpha, 3–4 months):

• build the missing part (dashboard/app);
• build the chat;
• add an ability to add another participant by SMS;
• create the basic workflow;
• build PDF generator;
• add SMS notification about the results are ready;
• release the alpha for a small group of users for a test location.

Third iteration (beta, 3+ months):

• build scheme generator and the rest of the necessary features;
• polish the UX/UI.

The team

Prototype:

• Designer (full-time)
• Project manager (half-time)
• Front-end developer (half-time)

Active development:

• Designer (full-time)
• Back-end Developer (full-time)
• 3 Front-end developers (full-time)
• Project Manager (one week per month)
• QA (one week per month)

Support:

• 1–2 Frontend Developer (full-time)
• Backend Developer (full-time)
• Designer (one week per month)
• QA (one week per month)

The more front-end developers we have, the quicker is development. One person-month is $X, QA is free.

Conclusion

Here you usually write an estimated price and time to build the product. :-)