Delivery in 3Phase
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 of predominantly engineers 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. 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. Try telling the DOE or a utility that after your first two-week sprint, you want to shuffle priorities. 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 because puns but also because it really has three discrete phases: Design, Development, and Delivery.
Phase 3: 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.
Phase 2: Development
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, 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.
Phase 1: Design
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.
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, and we often recommend fixing Design to exactly one month.
We try to get everyone to write down what they think they 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.