The Inquisitive Analyst on Working With Tight Constraints

A friend and former colleague of mine, Marcus Udokang, hosts and produces a podcast called The Inquisitive Analyst. Marcus interviews business analysts and project managers about their professional experience.

I’ve appeared twice: first in 2021, where I spoke about my career experience in FinTech, and in 2024, where our discussion was about how to maximize what you can get done with limited resources.

There were a few talking points from this most recent episode that I’d like to share here.

Managing Scope Creep

Question: What are the most effective ways to manage scope creep in IT projects with stringent constraints?

When a request comes in, ask: “if today was the launch date, and this feature wasn’t completed, would we postpone the launch?”

I was surprised recently - I was working with a project sponsor, we were scoping out work, we had to coordinate a delivery with an external party. To ensure we’d hit the timeline, we had really paired down the requirements to bare bones, what it would take to make the product work, rather than a great user experience. I’d suggested to the sponsor we get something basic working, I called it a “lite” version, to ensure we hit the deadline, and gradually improve the experience over time.

The sponsor indicated a great user experience was important, they didn’t want to launch an offering which just met basic requirements. And I asked, “We’ve committed to hit a date, if we had the bare bones requirements on that date, would we launch, or postpone the launch until we had a better user experience?”

And they responded, “we’d postpone the launch”.

Which was very important for the project team to understand - what we understood to be a hard constraint actually had some flexibility if we needed it, it was more important to deliver a better experience than hit the date.

Leveraging Automation

Question: How can automation tools be utilized to optimize workflows and reduce development time in resource-constrained environments?

Sometimes, manual processes make sense. I like the term “swivel-chair integration”: imagine taking data from one system, pivoting an office chair 45 degrees, and then typing the data in a second system. Automation doesn’t necessarily save time. Imagine you are launching a new feature or process. You assess an integration. And it might be a couple hours for a technical resource to dump data from one system, transform it, and update data in another. And it might take 3 weeks to build a process to bridge the two systems. Choosing a manual process makes sense - you would have to run it 60 times before you “break even” with automation.

And quite often, when you are launching something, this is the best way. It allows you to try an idea, and make quick changes, without ever having to write any code. Maybe the feature doesn’t have the take up you expected, and you can shut it down. But over time, the manual processes that live on, the time spent on them adds up, and resources you had allocated to building new things are just spending their time maintaining old ones.

Somehow, you need to foster a team that doesn’t just do things the way they’ve always been done, they’re looking for improvements. And probably, the best thing to do there is listen, be observant - where are people spending their time, ask questions. And be open when people bring things forward, and be willing to set aside time to work on these problems.

Technical Debt

Question: How can technical debt be managed and minimized during IT product development under tight constraints to ensure long-term sustainability?

• If you can, try not to fall too far behind. If your project has dependencies, try to keep them current. If you are updating your dependencies all the time, the changes are smaller and easier.
• Ensure there is broad visibility to challenges. Anyone running a line of business with internet connected systems will be aware of the cyber security risks associated with some of this technical debt, and will consider this information as they allocate resources.

Finally, be opportunistic - look for the opportunity to address debt and improve processes at every opportunity.

For example, the system I work on sends a lot of servicing emails - think welcome emails, password reset emails, account profile change emails. We work with different financial institutions, each with different branding requirements. When we onboarded a new client, we copied, and then modified, existing templates. Every time we made a change to an email, multiple templates have to be updated and tested against various email platforms. It was a process that was designed when we had fewer templates, and we just added to the existing process every time we onboarded a new client. It became challenging to make updates.

You can’t expect your executive team to propose an initiative to simplify email templates - they don’t know how the emails work. They’ll ask to onboard a new client, and expect that the emails will look right, and it’s up to the delivery team to do this efficiently.

In our case, on one occasion, we had to make a change that impacted a huge number of these templates.

A developer on our team recognized the challenge, and proposed a new solution. Rather the update hundreds of templates with our in-house templating engine, they recognized that the email service we leveraged had a much better templating engine. They consolidated our templates by introducing the branding as a variable, migrated them to our email service, AND incorporated the required changes. This also simplified QA.

Back to managing technical debt, if we look at this change:

• We were going to allocate a ton of time to modify 100s of email templates in an in-house technical solution
• But instead, we spent effort on consolidating templates, and moving to a better templating system that we already had access to
• We retired our in-house email templating system

To recap, look for opportunities to address technical debt. Ensure everyone has some space, everyone is receptive to trying new things, and provide a safe environment where individual contributors can express they’re spending too much time on email templates. And when they do, allocate time to revamp the process. Or if you are the person responsible for updating templates, and find yourself spending a lot of time doing a repetitive update - set aside some time to look for a better way.