Our client creates complex hardware components for the power and energy storage industry.
The work needed to update the client’s website was unknown and hard to price. Both Solspace and the client needed to define it better.
Create a project to price the project. But, do it in such a way that provides value to the client.
We not only successfully defined the project scope but did it in such a way to make the initial project valuable to the client; both extra and necessary.
We created flow charts to help us and the client determine what really needed to happen on the next website. This will help customers flow better too.
This type of work is right in our sweet spot. Customized approaches for complex problems are the foundation of creative development; just the way we like it.
The type of work Solspace does for our clients generally falls into one of two models: a total project price or a monthly retainer. That's an oversimplification, but it's also a pretty standard approach in the web development and programming world for most agencies. It’s this project work that can trouble us all, providers and clients alike. The question that everyone is tired of asking but has to anyway: How much will this cost?
Agencies don’t want to get upside down on hours, and clients don’t want to pay more than they have to. Now, even if you have a good and trusting relationship with your client, having to go to them and explain the original estimate was wrong is never a fun conversation. But “hope for the best and plan for the worst” isn’t a great strategy for either client or agency.
That’s why we recommend the Project Before the Project approach.
This is a project that’s used to scope out all the needs and work for the “real” project. We’re not the first to suggest this and far from the first to use it. Though, it’s given us both good work for fair money and clients that are happy and at ease, mainly because we included an element that’s often missing from this approach.
The process generally ends in a written document based on some discussions between client and developers to determine what work is required. That’s probably obvious enough. But, for the client this documentation often just feels like paying to be offered another contract. It contains a lot of “We will do this but not that” language in a long typed document. They’re geared primarily toward pricing, not progressing the project. To the client it feels like they went to project land and all they got was this lousy document.
Progressing the work has to be a key element of the initial project, not just pricing for the agency. We recently used this method with our client to great success. They offer technology hardware components for the electrical and power storage industry: everything from electric vehicles to particle accelerators. Customers using their website need to review a lot of very technical documentation and compile a set of products that are specially configured for their individual needs. It’s mission critical that the website flow well for customers.
The website updates involved restructuring how the products and the documentation was presented so users experienced a better flow through the process. But, like we said, their products and processes are deeply complex. So, we needed to create a complex (but digestible) model. It’s this model and the activities we used to create it that gave this project its self-contained value.
(Flow diagrams have super powers.)
Our lead developer, Ivars, used this project time to work closely with our client to precisely map out every product configuration experience that needed to be updated on the website before writing any code to make it happen. And, it’s true that those flow charts gave us a much clearer idea of what the scope of work would be to implement the changes on the website. We were able to give the client a very tight project price for the future work.
But, the work that is presented in those flow charts is about much more than just scope or pricing. The process allowed the client to uncover some configuration activities that were no longer relevant to them or their customers and some streamlining to how they offer products, among other things. What it really did for the client was give some documented realizations that they could then use within their company to update how they did things on the website. The flow charts and supporting documents had their own self-contained value for the client. Theoretically, if they walked away from Solspace after delivery they’d have documentation that was inherently useful for them and some other development agency.
Naturally, they didn’t go somewhere else; why would they? But they could, and that’s the point. We used the act of discovery to offer the client a plan and references that helped them do their work better, even without a line of new code. Programming still needed to be done, but they already had something they could use - something of value.
That’s the takeaway: use the project before the project to get a clearer idea of what needs to be done so you can create an accurate scope. But also make sure the work of this “pricing project” offers your client something of true business value. Something they can use even before the code gets created. It’s what they’re paying for.