Project Consulting Orientations: Navigating Change and Uncertainty

While it’s true Atomic Object builds software, it’s not our real product. As a software development consultancy, clients who engage with us typically end up with software, but the thing we’re really selling and predominantly evaluated on is the project. It’s both the experience for the stakeholders we’re working with and the repercussions for their organization, whether from the software or the learning that happened while building it. Whether or not it accomplished its goals is a significant part of it but far from the only thing. The most successful projects can end up far afield of the original plan.

Defining Success

Success for a project overlaps with, but is also distinct from, the success of the resulting software. For software, you can measure success by whether and how it provides value to users, whether it can attract them and be used successfully, and how it solves problems for the business. With a software project, there’s more to it.

• If software is produced, it maximizes the success criteria above in the context of the client’s goals, while working within time, budget, and technology constraints.
• The team handled risks and challenges well and wrapped the project up successfully in the eyes of the client.
• The organization got at least as much value from the engagement they expected — ideally more.
• Key stakeholders feel we were great to work with. They felt we listened and valued them, they learned and grew from the experience, they had fun, felt supported, and looked good in the eyes of their broader organization because of what we accomplished together.

While these aren’t all of the criteria for a successful project, they are certainly crucial. And the interesting thing about project success is that many of the criteria are more about the people involved than they are about the software itself. Did they walk away from the experience with positive feelings and associations, and a perception that we excelled as trusted advisors? As executors of software and project craft? That they liked us and like working with us?

Achieving this success relies on a sea of little details about how the team met the specific challenges of the project. However, I’ve found it’s good to have a guiding principle for how the Atomic team orients itself to the client and project — a sort of governing principle for how we approach the challenges we’re faced with. One angle to consider is what I call Project Consulting Orientation.

Project Consulting Orientation refers to how the team is positioning itself to navigate the change and uncertainty inherent in the project. Typically, teams use one of three strategies:

• A Responsive Orientation is one in which the team largely follows the lead of the client. The team defers to the client’s frame of what needs to be done, their conception of how it should be designed (and possibly engineered), and the team plugs into their existing processes.
• A Change Agent Orientation is one in which the team is attempting to enact change within the client organization by supporting or advocating the adoption of new processes, structures, or engineering culture. The client team recognizes a need for change and is looking to Atomic to tell them what that change should be.
• A Consultative Orientation falls in the middle of the first two. This orientation is one in which the team is a trusted advisor of the client and takes more of a leadership role in the project direction. By reexamining or rephrasing the root goals and crafting the execution strategy, the team helps maximize and multiply the upsides the project might effect. In this orientation, the team is “leading the way” through the project toward a successful outcome while still adapting to the needs and culture of the client.

Let’s take a closer look at each of these.

Responsive Orientation

The responsive orientation is one in which the team acts as a group of craftspeople, plying their trade toward the client’s goal, at the client’s direction. As professionals, they don’t need to be told the details of how to write lines of code or estimate a task, but they’re executing on a vision provided by a client in a way directed by the client, or via a simple path from the status quo toward that vision. What the client wants is what the team will do, providing advice when there are opportunities to cut costs and making the decisions necessary to execute the vision.

Of the orientations, this is the most deferential to the client. It works best when the client knows the work to be done well and is able to give clear, reasonably precise direction. Clients with their own technical stakeholders who are willing to own the outcomes associated with their technical direction are a good fit for this orientation, but there are tradeoffs.

Tradeoffs

• Pro – For clients with a strong vision and an expectation of being “in the driver’s seat,” this orientation empowers them to execute accordingly.
• Pro – This approach harmonizes well with staff augmentation engagements and is an easy onramp to collaboration.
• Pro – This orientation requires less capitalization of time and budget in project strategy activities, allowing for a greater proportion of investment into sheer maker output.
• Pro – This orientation is in easier reach for fractionally allocated or less-experienced team leads. This provides a good basis for a successful project when the time/budget capitalization for a more strategic orientation is out of reach.
• Con – A lot depends on the client’s idea for how the project should be executed, and this orientation may be more likely to lead to project trouble absent sufficient expert input.
• Con – Clients who want and need more guidance may not feel they got the value they were looking for out of an engagement with the consultancy.
• Risk – Absent sufficient influence over process and backlog, the team can end up with an unfulfilling, frustrating, or even unproductive work environment. This can sap team energy and morale, which reduces value delivered to the client and a disengaging experience for the team.

Change Agent Orientation

In some cases, a client organization is ripe for change and looking for Atomic to show them the way. This project consulting orientation is characterized by a project focus on helping the client converge on a better way of operating by adopting practices used at Atomic. For example:

• An organization transitioning from software development as a peripheral operational/IT concern to a core part of their value proposition and operations.
• A development team with an ineffective process being led toward more effective agile practices.
• Individual developers looking to level up engineering quality, such as instituting automated testing practices, refactoring their codebase, etc.

This orientation takes a “here’s how to change for the better” approach. It focuses on a clear-eyed assessment of the status quo and direct advice on how to adapt for more future success in software development, agile process, and/or product management. It has the greatest potential for big impact, and long-term value to the client organization when met with a receptive audience.

The big challenge with this approach is that the audience is often not uniformly receptive. Even if they are, it is treacherously easy to come across as pushy or arrogant and erode trust in your message. It becomes imperative to ensure each stakeholder is onboard that:

1. Change is needed.
2. The correct change is as Atomic prescribes.
3. Time and resources necessary are present/will be provided.
4. The Atomic team appreciates their individual efforts and understands their situation.

Absent these, recommendations will be met with resistance or rejected outright. Furthermore, team members will have differing perspectives and incentives based on their vantage points and may have contrasting opinions on the problems and their solutions.

Due to these challenges, I usually recommend avoiding this project consulting orientation for projects that also include Atomic involvement in development work. Pushing for change from the outside of an organization is likely to get people mad and damage trust with some stakeholders, and all too often those stakeholders are crucial to an effective and productive development engagement.

Tradeoffs

• Pro – Can provide high-impact insight and advice to an organization that seeks it.
• Pro – In some cases, significant change is necessary for the client to achieve success, and this approach draws out that need and forces reconciliation early.
• Con – This approach will usually ruffle feathers and damage relationships, absent unusually broad buy-in of the need for change and the recommendations.
• Con – The tension this approach creates degrades opportunity for collaboration, making simultaneous software development work more difficult, higher stress, or ultimately unproductive.
• Risk – Even when some key stakeholders think their organization or team needs change, individuals may not be receptive. This orientation gambles with that risk instead of mitigating it.
• Recommendation – Isolate “change agent” work to dedicated consulting gigs, decoupling development work or making it contingent on the buy-in of the change-agent outcomes.

Consultative Orientation

In the consultative orientation, the team or a subset works as a strategic partner with the client, helping to craft the project goals and approach to maximize the value to the client. This includes top-to-bottom adaptation of process, design, and architecture to formulate an approach that best meets the client’s goals.

The responsive orientation is one in which the team conforms to client expectations and executes on their vision, while the change agent orientation helps push the client into new ways of operating to support longer-term success. The consultative orientation strikes a balance somewhere in the middle. It seeks to design the project experience and execution strategy to fit the organization’s needs, stakeholder expectations and tolerance for change, project constraints, and both near- and long-term goals.

“Designing to fit” has a lot of nuance in this context and involves making trade-offs to find the best balance between execution within the status quo and effecting change:

• Product: Channeling the client’s goals and aspirations, and crafting a design/approach that both meets those needs while also delivering more than they were expecting. Push back when necessary for high-value wins.
• Process: Adapting our process to fit the client and their organization, while building trust and pushing for reciprocal adaptation where feasible and for the good of the project and team.
• Project Strategy: Crafting a plan that meets the client’s needs and maximizes ROI by exploiting opportunities, right-sizes investment to pay-off, and front-loads the mitigation of risk.

To make this happen, a consultative team needs to build and spend relational capital wisely by gradually building trust and showing results. The team can then leverage that trust for high-leverage course adjustments. They can do that by showing the client how an adjusted plan better meets their needs at lower risk, how a tweak to process will address a pain point they’ve explicitly acknowledged, or how an adjustment to design will support a broader range of future needs at a reduced cost. The consultative team earns the trust to take the lead and leads in directions where there’s an adequate appetite for the necessary change from status quo and project expectations. They must do this all while avoiding highly contentious, low-value confrontations.

Tradeoffs

• Pro – Can maximize the value delivered to the client by optimizing the project and product to fit.
• Pro – Improves the client project experience by having a trusted advisor helping to provide stability and expertise in navigating a challenging, high-stakes project.
• Pro – Supports a high-value, long-term partnership between client and consultancy.
• Pro – Provides latitude to the team to think expansively about how best to approach the project. This creates opportunities for growth and creativity that will help get the best out of individual team members and create a positive project experience.
• Con – Building the necessary understanding and relationships, crafting the strategy, and communicating it all take time and therefore budget.
• Con – Organizations with rigid expectations and/or processes may obviate the upsides while incurring the additional cost, collapsing this approach to either a Responsive or Change Agent orientation.
• Constraint – Limited by time and skill set alignment of senior consultants on the team.

A Preference for the Consultative Orientation

Each of these project consulting orientations has its place. That said, I think there are some good rules of thumb I recommend for Atomic teams in general:

• Generally prefer a Consultative orientation on your projects to build trust and maximize impact.
• Use a Responsive orientation early on with clients who have a strong vision for what should be done and how to do it. Build trust and look for opportunities to transition to Consultative if it seems like that would be a better fit. The sooner you make this transition, the better. Relationships/power dynamics calcify quickly, and it can become harder to transition as the project goes on.
• Avoid the Change Agent orientation except in specific dedicated consulting engagements, such as when brought in to provide advice to a client development team, perform due diligence evaluations, etc.
• Even when Change Agent seems appropriate, a Consultative orientation is often just as effective or more so at lower risk. If the motivations are in place to support a Change Agent orientation, a Consultative orientation will head in a similar direction if time and resources permit. The difference is, in effect, show via collaborative partnership versus tell via prescribed changes.