Software creates infinite possibilities, so having a way to define what needs to be done and how to measure when it is done is vital to the success of the project. It’s taken me years to polish this process. It all started back in the mid-eighties with one of my very first clients when I was 19 and still in college.
My First Project
I started working for this guy who was manufacturer’s rep. Let’s call him Tom. He wanted a very simple system and since there weren’t many people that could make something like this at the time, I was a great fit for the project.
The Actual Computer I Used For This Project
I gathered the requirements of what needed to be built. We agreed on a price, and I started building. As the system started to take shape, Tom was seeng it evolve, and began to come up with different exceptions and more advanced capabilities.
Tom would say, What if we could do this too? or It also needs to do this. All of these different scenarios were not originally talked about for the project, but since I did not have everything defined and documented, there was no way for me to go back and say “well that is out of the scope of what we agreed on.”
“I backed into how much time it actually took me, and I ended up getting paid about 5 cents an hour.”
I was only 19 at the time. I was thinking oh he must be right. I didn’t complete the project as we had thought because it didn’t do all of the things that he wanted. I wanted to please him and do a good job, so I could have a reference able customer.
Since we didn’t have anything documented, I ended it as best as I could knowing that it did everything he wanted and tons more than originally talked about. I backed into how much time it actually took me, and I ended up getting paid about 5 cents an hour.
It still wasn’t perfect. It wasn’t ever going to be perfect, because with any business technology, it is constantly going to evolve and I didn’t realize that at the time.
"And there's nothing wrong with that, if you can manage it properly."
What was “version 1” of this system was probably actually version 8 or so. I knew what I was doing development wise, but it wasn’t until later on that I realized the imagination of the client’s as they started to see these systems take place is going to expand and they are going to want to add to or change what they originally asked for. And there’s nothing wrong with that, if you can manage that properly.
At times, there’s this misunderstanding by business people that you build the whole system at one time and you have to come up with every possible scenario up front.
It’s nearly impossible to come up with every possible scenario you will run into before anything is started. You may know what the end goal is and the major features, but the devils in the details, and all of those small things that come up while testing are what makes projects never ending if there is not proper documentation. Just like what happened with my project with Tom.
What I Learned
One of the valuable lessons from that and through the years was getting better at providing the expectation of what I could do for the client, and what I could know was possible before I started building anything. I've been able to fine tune the process of scoping a project, and I've learned that, naturally business people are going to come up with ideas as we give them a better picture of what their system is going to look like. By having a process in place that allows for these ideas to be implemented, results in successful projects where both sides are happy.
Fun fact: 31 years later "Tom" is still a client here at Black Line.
Want to talk about your project?
You can learn more about The Software Development Process we use at Black Line here or If you want to talk to me directly about your project, contact us here or call (630) 388-1700 and ask for Jody!