We are often asked about what our engagement process looks like. Engagements will vary based on the needs of the client, but here we would like to go into detail about what an ideal engagement looks like, when Tempest House is handling the development end-to-end for a client.

I learned early in my career the importance of Product/Project Management that includes proper discovery and planning. To give an example, the first start up I worked for had no direction, planning, or discovery put into the project. The expectations and road map were based mostly on a whim and changed constantly. The end result was a project that last 5 years, losing money all the while, when at most it should have taken 1 year to complete. In the end the company failed, despite being at its core a great idea, just poorly executed.

Tempest House process is something we have refined for more than 10 years. We find it facilitates the best outcomes for our clients by helping them first figure out the ideal project they would like to build by doing the following:

1. Helping the client figure out what the best product is that they could build for their needs.
2. Giving the client the most accurate estimation possible for the work that needs to be done to build their desired product.
3. Giving our developers a clear road map of the work, so effort (and money) is not wasted, and minimal revisions will need to be made.

A little time spent in discovery upfront can save substantial time and money in development, and help ensure the end product is what the client wants and expects, and is something which everyone can be proud of.

Here is a quick breakdown of the Tempest House end-to-end engagement, including the planning and development process:

High Level Planning (figure out what needs to be built, and how best to build it in broad strokes)

1. Initiation: A client comes to us with an idea for a project, or we come up with one ourselves.
2. Investigation: The Product Management Team works with the materials we have on hand as well as conducting interviews and doing market research.
3. High-level Definition: Working closely with the Product Management Team, we write a high-level document that describes all the features in the project.

Cost and Resources Evaluation (Figure out what it will cost to build the project, and what resources are needed)

1. Hours Estimation: Using our high-level definition, we build a spreadsheet that helps us estimate the number of hours a project will take.
2. Cost Estimate: We take the hours estimate, and breakdown how many hours each team member will work, along with their hourly rate in a separate spreadsheet to come up with a cost estimate for the project.
3. Refinement: With the cost estimate ready, we often will work with the client to add/remove features from our MVP to build the best product possible that fits in the client’s budget and timeline.

Project Definition (Build the documentation so the team knows what they are building, and can do it right the first time)

1. Full Definition: The Product Management Team, along with the Graphic and UI/UX Designers, set to work on building wireframes, mockups, and full descriptions for all the features of the project.
2. Epic & User Story Generation: We break the specification down into high level Epics (groups of features) and user Stories (features).
3. Points Estimation: We assign a point value to each feature based on it’s complexity so we can track our “Velocity” on the project.
4. Build the Backlog: We move the tickets we want to work on to our backlog of tickets, organized by priority.

Development Begins (the team begins development work on the project)

1. First Sprint: The first Sprint of the project kicks off. The results of this 2-week Sprint will help advise the rest of the Project Development.
2. Sprint Retrospective: At the end of the Sprint, the team earns points toward Velocity for tickets that were completed.
3. Validate Estimation: The team goes through the tickets in the backlog for this Sprint and the next, and verifies all points values for the tickets.
4. Update Roadmap: The Roadmap is updated based on a ticket’s Business Value as compared to their points.

Development Continues Until Done

1. Sprint Planning: Based on average Velocity, we will accept Stories into the Sprint that we can get done in a 2 week window
2. Sprint: This is 2 weeks of undisturbed development. During a Sprint, developers move tickets through the workflow.
3. Demo: We review the accomplishments of the Sprint with all developers and stakeholders present.
4. Final validation: We use Continuous Integration Systems to first deploy our code to an environment for QA to verify everything before release.
5. Release Project Version: The current version of the project is made live.

‍

‍

‍

‍