Every step along the path to delivering a software project is a trade-off. Time and/or money are in short supply relative to the vision for a product, and every decision must be made with care. Moreover, there’s no one “correct” way to design or a build a feature—there are many possibilities, each with their own cost, time to implement, possibility for reuse, desirability, and maintenance burden.
A skilled team, therefore, does not merely learn a desired feature set and estimate and implement those features one by one. A team that’s really dedicated to great service shrewdly chooses among the possibilities to advance their customer’s interests as much as possible with every hour spent.
Maximizing value starts with the underlying business need. Customers come to Atomic Object with differing levels of detail as to why they need software and what they expect it to do. At one extreme, I’ve worked with clients who arrive at Atomic with a detailed and specific vision for what the feature set should be and how it should work. At the other end of the spectrum are customers with a known problem and a suspicion that software is part of the solution, but no preconceived notions about what, exactly, that software will be.
No matter what the specifics are, all of our customers come to us with one thing in common: they’re trying to advance the interests of their organization by finding a solution to a problem which fits a complicated set of constraints, and they care deeply about achieving the best possible outcome.
Our projects begin with a phase we call Research, Design, and Planning, or RDP. During the research portion of RDP, our teams interview project stakeholders and potential users to deeply understand the problem being solved, the constraints governing its solution, and the values, business model, and goals of the client organization. We play innovation games with our customer to understand their goals, to help us put ourselves in their shoes to evaluate options as they would. In many cases, there are many stakeholders with differing, sometimes competing concerns. Even so, our goal is the same: understand the real motivation for the project and what’s most important so we can strike the best possible balance for our customers.
During the design and planning activities of RDP, we combine our understanding of and empathy for our customer with our expertise as software designers, architects, and project managers. We deconstruct existing notions and designs for the product, looking for avenues and options that may deliver more value, now and in the future. We work in cycles, brainstorming, recombining, and exploring options for leverage and reuse to converge on a product design and development timeline which best advances our customer’s interests, minimizes risk, simplifies long-term maintenance, and is best positioned for future adaptation to evolving business realities and needs.
But RDP is just the beginning of a project, and just the start of our quest to deliver as much value as possible to our client. Software development is a journey of discovery: continual learning of constraints, discovering secondary or tertiary goals, sifting data and analytics to understand which parts of an application are most heavily used. As such, the process of maximizing value started during RDP continues throughout a project — with every software development sprint we continue to explore the design space and readjust our approach to ensure we’re always on the best track based on current information.
This practice of maximizing value is what distinguishes a good team from a great one. All the skill in the world won’t combat solving the wrong problem or being wasteful with time. Our teams know this. They’re skilled in their craft — great designers, developers — but, critically, they aim to apply that craft in the way best aligned with their customer. They aim that every dollar of value they can generate with their time should be and is captured by their customer.
Very interesting post Drew. I really see the value of this approach in client engagements. It seems to me that you start this RDP phase once the project is ongoing. If it has the potential to so drastically change the solution to the problem and therefore the work involved, on which basis do you come to the project budget beforehand? And how do you convince them to assign that budget when there is no agreed upon solution at that stage.
I’ve been reading your project approach methodology and find it really interesting and innovative, but have a hard time understanding how you manage to sell it to clients.
Good question, Alex.
We do quite a bit of estimation and planning during the sales process. Our estimates are risk-buffered and based on a plausible implementation plan by an experienced consultant. These estimates usually do a good job of ensuring a project is not under-capitalized. (More info on our technique here: https://atomicobject.com/client-resources/better-custom-software-estimates)
In my experience, this “maximizing value” approach doesn’t so much have an impact on the total cost, so much as boost the likelihood that the customer gets what they want, or more, out of the engagement within the agreed-upon budget:
Because we don’t spend too much time on something relatively unimportant, more time is available for what really is.
Because we’ve helped shepherd the design and feature set in a direction that leads to reuse and leverage, we miss estimates less frequently and deliver features under budget more often.
Because we accumulate some amount of budget windfall (with a bit of luck), more “can it also” questions can be answered with “yes” instead of “not within the current budget and scope”.
In the best and most extreme cases, this leads to a virtuous cycle in which the end product is richer and more powerful than originally planned and budgeted for. Customers aren’t usually aware when we over-deliver – they’re just pleased with the engagement and its product.