One of the complaints that I’ve heard most often from engineers in various industries is about the requirements shift that often happens midway through a project. It’s a common refrain: “I had almost finished the project, and then my boss told me to do everything in a totally different way. Why can’t they just make up their minds?”
I’ve only ever worked at small companies where the design decisions were fairly transparent. With only two levels between me and the CEO, it was always pretty obvious why any change was being made. In general I haven’t had to deal with this issue very much in my career, but up to now I’ve been sympathetic to those people who have. A recent project that I worked on gave me some insight into requirement shift from a manager’s perspective, and I now have a lot more respect for projects that experience a lot of shift and upheaval.
A few weeks ago I decided to build myself a frisbot. My idea was to mount some photo-sensors a two wheeled chassis (each wheel would be a frisbee, hence “frisbot”). The bot would then be able to follow a light around. I had a good idea of how I wanted to design the electronics (finally using that MSP430 launchpad I got a while ago), but I wasn’t sure how I wanted to build the chassis. I was thinking a simple plank of wood with the various components mounted to it, but I hadn’t thought much farther than that. I convinced my friend Jared, who has an irrepressible drafting habit, to help me out with the mechanical design.
The two of us sat down and I showed him some videos of other frisbots, and showed him the different electrical components that had to fit on the chassis and we talked a bit about the design. Then we split up and got to work, I wrestled with the MSP430 DAC and he started drafting out the chassis design. Since I hadn’t really done much to spec out the chassis, Jared started asking a few questions about the chassis.
Him: How do you want the motors attached? Can we just mount them on wooden plates perpendicular to the base?
Me: Sure that works. Oh, but can you make them easy to remove so that I can replace the motors later if I want? And add some space to allow bigger motors in the future?
Later
Jared: Ok, the motors plates are done. And you were going to put the dev board here? (points to his design)
Me: Ya, that’s what I was thinking. Oh, wait! I might want to use a different microcontroller later, can you make the space for it larger?
We went through a few rounds of questions like this. He would ask for clarification, and I’d suddenly realize that we could do something slightly differently and make for a better or more flexible design. Admittedly, if I’d spec’d the thing out beforehand this probably would have gone a lot more smoothly. Jared, nice guy that he is, didn’t punch me in the face even after I asked him to change things for the fourth time.
The main point of this story is that the reason for requirement shift is because you don’t know everything you need to do until you’re actually working on it. That’s when a lot of questions get answered. Even if I had written down a full specification for the chassis beforehand, some of Jared’s questions spurred me to think of things that I wouldn’t have even considered beforehand, like adding a crossbrace to the motor plate. The act of making it changed what I thought was best and informed a lot of the design decisions.
Generalizing from this one experience, it seems that requirement shift on a project means you’re doing something new. If you’ve done it before, you know how to do it and don’t have to worry about changing the design halfway through. But if you’ve done it before, then it’s boring. One of the main reasons I like to design and build things is that it’s an educational and inspiring experience. If I only ever build things that I know how to make, then I’m not learning anything or doing interesting things. Even something that was once interesting can become mundane and boring after you’ve done it enough. Having to rethink a design halfway through is actually why I do what I do.
I think one of the main reasons that people complain about requirement shift so much is that in larger companies, the engineers are often isolated from many design decisions. They’re so removed from the design process that they don’t get to experience the wonder of discovery that happens when you realize you have to do something different. It’s not a problem with requirement shift, it’s a problem with openness in the company. This may be why startups don’t have a problem with it. Everyone in the startup gets to experience the fun parts of the design, so they don’t balk when things change.
If you don’t have requirements shift, you’re doing something easy and boring.