Our clients come from diverse backgrounds and company sizes, with varying budgets, expectations, and software experience. A one-size-fits-all process won’t work, so consultancies like Atomic should lean into tailored projects for individual clients and situations. In this post, I’ll share of the key differences, why a dogmatic process is not the way to go, and some of the tools and approaches we use to be flexbile.
Software and the need for custom software is everywhere. Clients range from scrappy startups to large enterprises, each with unique organizational structures, decision-making processes, and technical sophistication. As a result, there’s a wide spectrum of fundamental differences we see from project to project:
- Budgets can vary from $50,000 for an MVP to $5M or higher for a full-scale system or complex modernization. This requires scaling of team roles/size, the development process and project management.
- Expectations differ – some clients want to be closely involved in day-to-day decisions, while others prefer a “black box” approach, needing adaptable communication cadences.
- Technical expertise of client team members spans complete novices to seasoned engineers, necessitating flexible training, documentation, and collaboration models.
- Company cultures can be risk-averse and waterfall-oriented or fast-paced and agile, impacting desired project rhythms and review processes.
Tailored Projects vs. the Worse Alternative
The alternative to flexibility is a more on-the-rails dogmatic process. Following the same practices for each client has its advantages– mainly for the vendor, not the client. It’s easier for teams to bring the same practices to bear for each engagement, and there may be some advantage to perfecting those practices. However, rigid & prescriptive processes fail to account for the realities of custom software projects:
- Inflexible prescribed milestone-based deliverables may fail to capture the actual discovered needs of the business and users once the project is underway.
- Documentation requirements that work for a $1M project are overkill for a $100k MVP, creating unnecessary overhead.
- Similarly, design practices should be right-sized for the engagement and take into account the work that the client has (typically) already done. Design is an area where more effort can lead to more certainty of product-market fit, but less effort still has value.
- Communication cadences optimized for co-located agile teams don’t translate to globally distributed workforces with time zone challenges. Conversely, co-located teams should get out of Zoom as much as possible.
- Finally, a full Scrum implementation is overkill for a small team with limited resources, but a consultant’s dogmatic adherence prevents optimization.
Inflexible timelines, documentation requirements, or communication cadences frustrate clients and inhibit progress. Over-engineered process elements slow down decision-making and delivery, which can undermine the client’s confidence and degrade the team morale. One-size-fits-all methodologies also ignore the uniqueness of any project situation, the teams’ skills, and organizational cultures. What works with one customer won’t work well with another.
Tuning the Design and Development Process
The approach that works for us is to select from a toolkit of proven agile and human-centered design practices. My colleague, Kim Crawford, has been maintaining a series on some of the design thinking toolkit activities we find most useful. We also draw from agile frameworks like Scrum, Kanban and SAFE to assemble a tailored process (a simple example is for a shorter project we might opt for 1 week sprints). Once a we’ve struck a deal with a client, our teams select and sequence activities based on client context — not a checklist.
Regardless of how the process is tuned to start, it’s important to regularly review and adjust what’s working, and what could be improved with our client stakeholders. I think this takes some of the pressure off the team to guess at how well things are going, allows us to tweak our approachthoughtfully, it and reinforces that flexibility is baked into the process with all parties involved.
Embracing the Journey of Change
It’s important that consultancies cultivate a cultural mindset of flexibility and continuous improvement. Our people will be at their best and produce the best product when they expect the process to evolve as the project progresses and client needs shift. We should view each engagement as a chance to grow and learn as professionals, add to our toolkit, and enhance our experiences overall. I think this is a healthier way to approach work in general, but it sometimes means we’re a little outside our comfort zone. After all, maybe there is some truth to the adage that we should all become comfortable with being uncomfortable?