Creating Better Software Through Trust and Collaboration

Telling clients that we will deliver on time and on (or under!) budget is one of my most fulfilling moments as a technical program manager at GenUI. After years of change orders, budget extensions, and missed deadlines in other contexts, our clients are genuinely surprised and grateful that we keep our promises.

I understand their perspective. I’ve been on the other side of the fence, too. When I worked on the client side at a prominent software company, my team necessarily planned to spend double whatever an outside firm said they would charge. We had come to expect ongoing costs and extended timelines. 

The point here is not to boast about GenUI’s track record. Change orders and budget extensions still happen. But they shouldn’t be unpleasant surprises, and they shouldn’t be the normal way of doing business. 

In my experience, these problems are avoidable. The right approach to technology program management (TPM) can help deliver a better end product and make the journey more rewarding for everyone involved. I call it sustainable TPM. 

How we got here

The speed of the industry and focus on structure and process can sometimes cause software companies to lose sight of why they develop software in the first place. The traditional relationship has faltered for several reasons, including: 

1. Short-term mindsets lead to a focus on billing rather than value. The consulting business model forces people to think about billable hours rather than value delivered.

2. Legalistic approach due to fear of financial risk. This leads to an emphasis on documentation rather than true collaboration with a client. 

3. Low trust up front in an engagement: Rushing the pre-sales and kickoff phases can put teams at odds with one another because of a need for more agreement on the right solution.   

4. Walls between technical and business participants. Separating clients from developers can lead to misunderstandings and missing the mark with the final product.  

5. Lack of support for the development team. As the backbone of any project, development teams need wraparound support that they don't always get. 

When goals and interests are not fully shared and understood, missed expectations inevitably result. Approaching this relationship openly and flexibly will lead to much better outcomes—including higher-quality products and happier clients.

How to fix TPM to get better results

Over many years of creating software products, we’ve found that it’s possible to prevent these problems from arising and build healthier relationships with our clients. These principles can apply to any software development process, not just a consulting relationship.

Embracing change

The true nature of agility is not found in any Agile guidebook. True agility means nothing is set in stone, and everyone is prepared to pivot. Change should never come as a surprise. Embracing change allows us to maintain momentum.

In the software industry, change is inevitable. The direction of projects will change. Capabilities will change. The most effective solutions to problems will change. It’s usually good news when something is changing because it means we’re refining our process and heading in a better direction. While it’s often a good thing, this inevitable change means we must stay agile. When we see change first as a risk or cost, it creates resistance. Change often means a smarter, simpler, less expensive solution–assuming that the process can accommodate it. 

As far as we’re concerned, the days of waiting until you have detailed requirements to start development are gone. Engaging in contract updates during the project is a significant distraction for both parties. It erodes the trust that’s the basis for all functioning relationships. 

At GenUI, our agile approach is reinforced by flexible contracting that puts the client in the driver’s seat. We document their decisions and priorities as part of the project. We aim to work collaboratively with our clients to pivot as needed without being slowed down by formalities and paperwork. We find it’s possible to do this while keeping our bottom line intact. 

Our best projects happen when clients embrace change, too. As early as possible, we help clients clarify what they need and how best to accomplish it. It’s common—almost universal—that we build something that diverges from what our clients initially thought their users wanted.

This value-driven approach is the heart of the MVP (or, as I like to call it, the MLP: Minimum Lovable Product). Maintaining a change-aware software development process makes us understand that transformation is often the key to long-lasting product success.

Purpose

How do you maintain focus in an environment where everything is changing? With a clearly stated, universally understood business goal—in other words, understanding the “why” before the “what.” 

This is when we need to remind ourselves of the true purpose of software development. It’s not to develop a piece of software but to solve a problem. Everyone involved in a project should know the problem, why it matters, and who is affected. 

This common goal enables you to understand which kinds of change are truly valuable and which are just busywork. It allows you to ask and answer essential questions such as: 

• Are we solving the right problem?
• Are we focused on the correct functionality?
• What constitutes an MVP of this product?
• What else could we be doing that is more valuable?

A shared understanding of purpose was critical to success in a recent project with a biotech startup. Initially, our job was to migrate their data pipeline from AWS to Microsoft Azure at the behest of a big client they hoped to land. 

As the project evolved, we discovered many other improvements that would help meet their customers’ needs and improve their solutions. By understanding the business goal, we were able to help them in unexpected ways. At the same time, we focused on what added value, so we could do what they needed on time and within budget. We did it all in three months.

Our most exciting projects often result in us building something different than the client initially envisioned. Not because we made it in isolation based on a flawed or overly prescriptive SOW but because we figured out a faster, better, or cheaper way to achieve their goals.

Empathy 

Empathy sounds fluffy, but it’s a very pragmatic way to behave. For us, it means that we put ourselves in our customer’s shoes. We get passionate about the success of our clients as if it was our own—as if our livelihoods depended on it. What advice would we give our leadership about better, more secure, usable, or performant technical solutions? What are better ways of getting to market quicker and learning from users as soon as possible?

Empathy for our clients also manifests in our focus on listening and capturing ideas throughout the project. Sometimes what seems like a throwaway comment or a pie-in-the-sky wish becomes the pivot point for a project. Traditional change orders are like armor protecting you against inspiration. Instead, we present new ideas and opportunities for the project to the client throughout the process or at the end of the project as possible next steps for ongoing development.

Collaboration

Different people have different areas of expertise. It makes sense for developers to write code, project managers to wrangle spreadsheets, and product managers to make strategic decisions. However, when expertise becomes a prison, the product suffers. For example, when we expect developers ONLY to write code and not have a strategic viewpoint, or when project managers fear sharing their thoughts on a technical matter, it’s challenging to have a real conversation. People begin to distrust each other and guard resources. 

By eliminating the traditional “air gap” between areas of expertise, sustainable TPM prevents people from working in isolation. It embraces diverse viewpoints and understands that a great idea can come from anywhere. This keeps our team cohesive and able to revise as we go rather than discovering discrepancies toward the end of a project.

We don’t keep developers off in their own corners away from clients. We expect everyone on our team to talk to clients and each other. Of course, that means hiring developers who can understand business problems and articulate technical solutions in ways that other people can understand. Technical expertise is essential, but it’s only part of the job.

During our work with a leader in hospitality worker safety, we started by understanding what moved the needle for their clients’ end users. In the early stages, we gained insight from user interviews and experience design ideas provided by the client. Once we got going, one-on-one and small-group collaboration enabled real-time fixes that accelerated the project. Our partnership helped us to wrap up this ambitious project in under eight months.

Details, details

It may sound like sustainable TPM is a seat-of-the-pants affair, but it requires us to be on top of cost, timing, and other details in near-real-time. It demands that we constantly communicate with clients about what we’ve done, what’s left, and how changes will affect costs. Everyone involved in a project must stay on the same page throughout the process. That means being aware of potential silos and finding ways around them. 

Ongoing communication and collaboration create a somewhat more labor-intensive day-to day-process; however, this approach saves time and energy down the line because we avoid misunderstandings that may turn into crises. 

Outside of the relationship with our clients, we support our developers with a strong team. They’re constantly knocking down barriers and bridging gaps so that the technical experts have the space to do what they do best. 

In addition, we scale our support resources based on the actual needs of the project. For example, we use a fractional TPM strategy meaning that our clients will get the number of hours of TPM support needed by the project. In contrast, others in the industry may charge for full-time TPM support regardless. 

Our high-level architects and experts are available for an hour here and there to help move a project along. Of course, if a project truly needs a full-time TPM, then we make that happen. The goal is to use our most experienced people where they can do the most good.

Better Product, Better Process—Try a Sustainable TPM Approach

Our software development approach requires extra work in some areas, especially hiring, collaboration, resourcing, and project management. However, because it focuses on results, it saves massive amounts of time and money that would be wasted on inefficient processes and personnel churn. Most importantly, it builds trust and collaboration for better outcomes. 

Perhaps most importantly, it’s more sustainable than the traditional adversarial framework. People enjoy having their contributions heard and valued. Developers are more productive when they care about what they’re building and can see the results of their efforts. And clients love results in the form of happy end users, especially when those results are on time and within budget. 

Contact us if you’d like to discuss how we approach program management at GenUI.