Tuesday, February 6, 2007

Before there were projects

Though project management has been around for longer than I have been born, in the mid 80's I wasn't really exposed to the idea of software projects managed by project managers. As a programmer working in both an IT shop as well as consulting, life was much different.

I was assigned tasks by a manager (functional or account managers). Sometimes these tasks were very specific, such as "add this information to an existing report". Other times these tasks were more generic, such as "customer would like a new report that shows this kind of information". The requirements were always clear, but there was always flexibilty in the design. This applied to everything from traditional maintenance tasks (bug fixing, smaller enhancements) to major new product or system development from scratch. As a junior developer, I appreciated the extra support I had as I was learning the tools and systems necessary to excel at my job. Once I got there, I appreciated the flexibility that my manager gave me to figure out the solution with the customer more on my own. In other words, the tasks moved from specific to generic as my experience increased. It became my job to get to the details.

The manager was the initial "go-to" person when there were any questions. He or she needed to have a certain level of knowledge about what the customer wanted. However, they weren't the customer so their responsibility was to get clarity from the customer when needed. Sometimes, that could be done "off-line" so that I could focus on other things. Other times, it was determined that I needed to be there if the discussion became more technical in nature.

Another key difference is that there was little or no specifications. Essentially, most requests if written were a simple one page form providing some high-level information enough to get the conversation going. Other requests were verbal in nature. There were no project plans to review, drafting and review of a large functional specifications document, etc. So where did you capture this information, you ask?

Most of the conversations involved at that point were verbal, with the occassion taking of notes to go back to my desk. However, and here is the important part, the code WAS the specification. It represented the requirements and design. It was expected that you would go through several cycles of the changes. These weren't prototypes, but early looks at the finished product. At first, some things weren't finished or even developed yet. However, the point was to get feedback not just from the manager but many times from the end customer. "Are we on the right track?" "Is this what you were expecting?" In the process, we learned technical limitations such as "we had to redesign the report because the new data would not fit" and couldn't have expected some of those things until we got into the code.

As I progressed in my career, I look back to these early years and wonder if things are better now. Sure, technologies have changed but so have other things that perhaps have gotten in the way. All I know is that things seemed much faster in those days even though the technology was slower. But I have to believe that with improvements of technologies that things should be screaming now. However, they aren't. But that's a discussion for another day...

2 comments:

Greg Jackson said...

Was nice to stumble across your blog on google. (I was googling careeer advice on becoming a CTO and up popped your blog...)

Anyway, I'm halfway through my MBA now, and am currently enrolled in Operations management course where we are knee deep in "Six Sigma".

I'd fiddled with Six Sigma before in the past, While in Florida, but have now discovered a new interest in applying it directly to Software projects.

I Find it quite interesting and am also reading up on CMMI.

look forward to following your blog....

let's do lunch soon

Greg_jackson@Adp.com

Skip Angel said...

Hi Greg,

Good to hear from you again! Though I know very little about Six Sigma, from what I hear there are similar concepts in Lean. Perhaps you will be the best judge as I get into the details later.

Now, CMMI to me is another story, which I plan on addressing shortly. I find that there are many things that seem to be almost polar opposite to Lean/Agile principles. And this comes from a person who used to really be a fan of CMM/CMMI...