Swage: Dynamic Scenario-based Project Planning MVP
Here at Beach, we work with pre-seed, seed and series-A stage technology startups as well as with innovation teams in later stage startups and larger enterprises, that are effectively operating like earlier stage startups.
You know the common theme runs through all of our startup clients? Uncertainty, plain and simple.
Everything is up in the air. Everything is subject to change. Everything is scenario-driven, parameterised with assumptions, characterised by the likelihood of future events, known-unknowns occurring.
Bringing order to this uncertainty is a pain. A real f-ing pain.
Yet, uncertain scenarios are what startups trade in, it characterises the companies very existence. When raising money, however, presenting scenarios with confidence is necessary, because like it or not, bringing structure and order to the chaos is an absolute must for investors.
The good ones know that this isn’t the full picture, that scenarios and planning are more a representation of how well you’ve considered the full extent of your world, rather than the fixed 3 to 5 year business plan that the bad ones feel they need you lock onto as gospel (and use as a stick to beat you with for the next 12 months).
Still, every Startup we work with and has raised money (totalling more than $12m in the past 3 years), has had to work with multiple business planning scenarios and as the advising CTO, I’ve had to structure budgets, resource planning and roadmaps with many permutations that can be presented and discussed depending on the fundraising activity.
Here’s the scenario if we raise £200k convertible note with 12 month runway.
Here’s the scenario if we raise £750k equity round with high velocity, aggressive roadmap cycle.
Here’s the scenario if we get a first tranche in Q2 2019 and second tranche in Q4 based on hitting the milestones.
It goes on, we’ve seen them all.. and written scenarios for each.
But then, overnight…
Investment round closes. Money in the bank.
Scenario LOCKED IN. The fun starts…
Our scenario iterations are a form of pre-commitment. Expectations have been set, so much so that at least one of them was suitable enough to get through due diligence and is now what your investor has in mind and the business needs to prepare for — quickly.
Almost overnight, this scenario has become your existence.
All those CEO hyped sales-techniques designed to capture the imagination of potential investors, are now a reality.
Those 6 UI/UX designers you planned to hire in Month 1 post-investment — now your reality.
Those 3 mobile developers that you indicated were already working on the mobile app (whether they weren’t or not) — now your reality.
Moving from iterative scenario-based planning as part of an investor sales cycle into Production-oriented actual live scenario is a massive step and a destructive cause for chaos and ill-discipline in early stage companies.
No tooling in the market today can cope with this. We’ve tried them all, they all failed (at this, they still have their place in the integrated workflow).
- Asana, Trello, Jira, Notion — great for tasks and roadmap, not good for scenario iteration, budgeting and financial planning
- Smartsheets, Roadmap, ProductBoard — great for roadmaps and timelines, can’t deal with financial modelling and rapid iterations
- Xero, Wave, Quickbooks, FreeAgent — great for bookkeeping, terrible for Project planning
- Upwork, Hubstaff, Freelancer — great for managing outsourced contractors and distributed teams, terrible for Project planning, roadmapping and scenario building.
MVP 1 — Google Sheets
We started with a functional prototype built in Google Sheets, with a single core goal — speed of scenario iteration.
It worked very well.
Allowed for dynamic currency selection and real-time conversion (since our clients are all international) using GOOGLEFINANCE() functions
Lookup tables for Client Specific contract rate card, with roles and levels
Project Configuration to assign resources to Project, set dates etc.
All of this contributes to generating a Scenario Template tab— this is the key, with the ability to quickly add and iterate hours based on rules across the Scenario phase. As a simple example
Scenario 1 — Heat is On Scenario
Backend Developer 1 — Senior Level— Full-time 100% engaged
Backend Developer 2 — MidLevel— Full-time 100% engaged
Front-end Developer 1 — MidLevel — Full-time 100% engaged
Scenario 2 — Easy like Sunday Morning Scenario
Backend Developer 1 — Senior Level — Full-time 50% engaged
Front-end Developer 1 — MidLevel — Full-time 25% engaged
In reality there would be many more iterations, covering varying roadmap scope definitions, different technology stack decisions, different resource options (in-house, contract, near-shore, offshore, agency etc.), different development cadence levels and velocity, different budget allocations.
Our Google Sheet Scenario would pull through and populate the template for the assigned resources, separated by “Category” ie Development, Design, Project Management, Testing etc.
It would populate in weekly increments, the start date to finish date that the scenario covers.
I would then simply apply the weekly hours in the Time column, needed for each resource, based on my Scenario description and feeling for the cadence and profile of the development process. For example, with a 40 hours max working week, I would input 40 for 100% engagement, 20 for 50% part-time engagement, etc. etc.
I would do this in each of multiple tabs, duplicated and modified in the sheet and summarise them in a master sheet, normally to present to the CEO, CFO and for them to regurgitate into the business modelling and investor decks.
Once the Scenario was locked in, one of these tabs became the Actual.
The estimated values were carried over into actual, and then as the work progressed, the actual time was recorded.
Most of the time, this was used to provide visibility and real-time transparent reporting of Beach’s own developer resources being applied to a client project. This being the case, we also used it to track the Invoice cycles.
This is another key factor. Each client may have slightly different payment terms. Since we generally pay our staff on a weekly in arrears basis, it’s important to maintain our client Invoice and payment visibility for cashflow management.
So the sheet would also be manually updated when an invoice covering a particular period had been issued, was due, overdue or cleared and paid.
The sheet provided feedback in terms of the work effort being assigned on a weekly basis, and enabled easy visual comparison with the Scenario estimate.
You could even look at the comparison in a nice little chart, which serves the in-progress reviews (standups, weekly meetings) and retrospectives with useful information that can be discussed, learned from and applied in the inevitable future Scenario planning.
MVP 2 — Swage
I’ll cut to the chase, here’s a demo.
We’ve used the MVP 1 in live situations many times now. We have a feel for its absolutely clear benefits to the process and workflow.
But as with any iterative process, we’ve been able to see how Swage could be better and will improve from where we are now.
- Better structure for managing Projects, Scenarios and Jobs (active scenario)
- More complete user roles, access levels and policies — for clients, internal teams
- Improved reporting — cost v client sell price
- More complete configuration options for currencies, project timings, resources and rates
- Integrations with relevant services, such as accounting software, time-logging/work-diary software
- Better dashboard views
- Improved post-phase completion reporting
- Intelligence in monitoring Projects in progress
- Better overall UI/UX and presentation
- Better collaboration options
In order to make these improvements a reality, it was time to make a proper web application for Swage.
Here’s a few screenshots from the app, if the video is TLDR;
If you’re interested in the development stack, Swage consists of a Single Page Application (SPA), built with Vue.js.
The backend and APIs are provided by our open-source Beach Core engine, in a lightweight parent rails application.
Swage’s core business logic is in another rails engine, this one is a closed source private repository (one of the cool things about this architecture is ability to mix open-source and closed source engines, to control the intellectual property).