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.