Postpone technical details as long as possible, despite what your PM tells you

I’ve always been a firm believer that whether you’re Agile or Traditional, it’s important to postpone describing technical details as long as possible. It’s very tempting to start to solve problems ASAP, because there is something very satisfying about solving puzzles. Also, many project managers and others who are being held to deadlines will push to start design and coding as soon as possible. However, I believe in, as someone I met recently described it to me, a “back to basics” approach.

One challenge I often face is when a client pushes for me to start technical discussions with the users. Their argument is usually “Our business users are very technical. In fact sometimes they know the system better than we do!” They then want me to start discussing tables, files etc with the subject matter experts.

This logic is erroneous, and I’ll give an example in a minute. The reason it’s wrongheaded is that it is based on the idea that development teams are code monkeys. They’re a service centre. We tell them what to do, and they do it. This is a massive waste of potential. You need to think of your development people as technology experts and problem solvers, not coders and administrators. When they are given a chance, they can find ways to leverage technology to drive value, not just deliver a request. Good developers don’t just understand the inner workings of your current system. They also know the limitations of it, and they know of other technologies that can be leveraged to improve it.

An extreme example: A government client I worked with was reworking an old, green screen system for managing driving licenses and vehicle registrations. We started with our usual approach, but the project manager said that we were focused too much on business process. He needed screen flow, data flow and table structures. The people we were working with knew their work very well, some of them having 20+ years of experience, but when we moved away from business process to describe screen flow, they ended up describing modifications to the screens they’d used for 20 years, including screens for switching from the “License File” to the “Vehicle File” system. Some of their changes were quite novel, but the resulting screen flow was far from what a modern application was capable of. My coworker and I ended up providing two deliverables, the one the PM wanted, and another one based on business process. The company hired to develop the system used the business process based one.

Another more recent example. I’m working with company doing a rewrite of their client intake systems. We were told that the business process and data descriptions weren’t detailed enough. We should focus on field validations, screen flows and system level use cases. The result? A system where some of the data and business rule exceptions were easier to manage. IT took one look at it and said “We’re doing a rewrite. Why are we recreating the existing batch processing? What if we do real time processing and push errors to the user rather than our customer support team?” Potential savings in the hundreds of thousands of dollars. Part of the problem here was that the overall vision was not well understood by the end users, but the result was 2 days of workshops were wasted, spent on describing a system that abides by current technological constraints.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s