How We Deliver
Delivery in 3Phases.
After years of building software for energy companies, we've found a project cadence that works for all stakeholders - the utility, the developer, and everyone in between.
As a company with a heavy engineering presence we love continuous delivery. We don't practice the agile methodology by the book, but we do use its principles of small, constant integrations and frequent reassessment of goals to ensure our plan of action reflects the latest insights. We prefer short & constrained deadlines and a cadence that is familiar and distraction free.
Our clients, however, often require a fixed deliverable at the end of a several-months-long timeline (commonly called the “waterfall” approach). Try telling the DOE or a utility that after your first two-week sprint, you want to shuffle priorities given new knowledge. For projects whose requirements can take 3-12 months to gather and finalize, the product team simply cannot reassess priorities every two weeks.
Our delivery process blends the best of both worlds by balancing the risk of spending time building the wrong thing (waterfall's weakness) without the overhead / organizational shock of implementing something unfamiliar (agile's weakness). We call it 3Phase: Design, Development, and Delivery.
Taking a page out of Andy Grove's High Output Management, let's start with the end in mind.
Delivery doesn't just happen in a split second when a developer presses a LAUNCH button. All too often clients change copy, designers tweak views, PMs add features, and developers optimize code. Ignoring that Delivery is a phase and not a singular moment in time is why so many deadlines are missed.
To launch the best product we can, we give Delivery a full third of our time. By giving it the space it deserves, we test the final product on real users and make the high-value modifications that only become obvious when a product is live. To do so, Delivery starts when a product is ~90% complete. It is often more valuable to user-test a near-final product than it is to wait until it's pixel-perfect.
For complicated launches, especially where a UX is drastically changed and/or a significant amount of data is migrated, we will often create explicit Delivery schedules.
If Delivery is filled with demos, meetings, and lots of back-and-forth, the Development phase is ideally the opposite. To get to ~90% complete efficiently, the engineers need lots of quiet and uninterrupted time to build all of the project's requirements.
While the product may be 90% at the end of the Development phase, all of the product's environments, configurations, and deploy processes must be at 100%. All of these are usually completed by the engineering team during the Design phase, but if it slips, it cannot slip past the Development phase.
As the saying goes, “the alternative to good design is bad design, not no design at all.” Anything that matters must be designed before it is built, or it will surely be built poorly. This includes the UX and the UI, but also applies to the database schema and the app's component tree. It even includes project management expectations such as who's meeting when, where, and how frequently.
To ensure we're building the right things, for the right people, in the right way, we invest time into conducting research to understand stakeholder and end user needs, the market context, and anything else relevant to a particular project's goals and risk areas. Only then do we venture to propose and design solutions.
At the same time, there's a point where a product can be over-designed, especially when decisions are made by committee rather than an individual. We balance under- and over-designing by fixing the Design phase to a third of the total project schedule. Thereafter, if Design is planned for 3 weeks but stretches to two months, we can know with high certainty that Development and Delivery will slip, too. We've found that most utility contracts include ~3 months of requirements, in which case we often recommend fixing Design to exactly one month.
We surface what we collectively know about the final product, and then we identify everything we don't, including the data, inputs, outputs, calculations, and even the copy. Scoping deliberately ensures projects will be launched correctly, on time, and on budget.