Leadership

You promised it could do what?


Owing to the overwhelming response to my first three-part story in which Harold did NOT get fired but I did, I would like to try your patience with another fine tale, told in three installments.  This one takes place in the far distant past, early in my career when I believed that all salespeople knew what they were talking about and always told the truth.  It involves a Vice President, a tropical fish wholesaler and a naive but eager computer programmer - me.

Frank, the Vice President of the new microcomputer division, hired Tim, the hotshot computer programmer to go with him on sales calls hitting up the existing customer base with proposals for new custom software solutions.  The intention was to develop a wide range of vertical market applications that would take the world by storm, all sold on brand new Altos MP/M systems (wow, how old are you Tim?) at $30,000 a pop with a whopping 5MB hard drive.

"So, Mr. Customer, what exactly would you like that new inventory and sales program to do for you?" pumped Frank.  "My programmer will take notes and let us know if it can be done."  Mr. Customer, who used timesharing on a DEC PDP-11 was not used to hearing such talk about possibilities, only limitations.  "The microcomputer is a whole new world, Mr. Customer," crooned Frank, "it can do whatever you want it to do."  I was beginning to get a little nervous.

I listened carefully and furiously took copious notes while Mr. Customer drooled and slathered about his dream for a multi-user inventory control and sales invoicing system with bells and whistles that should have been setting off bells in any experienced programmers head.  Unfortunately, this was Tim's first gig with the big dogs.  All his previous success had been programming in Applesoft on an Apple II+.  He had now graduated to the new world of dBASE II.  Wow!

"So, what do you think, Tim?" asked Frank, "Do you think it can be done?"  I swallowed hard.  What should I say?  "Sure, it can be done," I replied nonchalantly.  "That's just like the job I did for the mobile medical imaging company just a few months back.  This should be a piece of cake."  All stood up to go with handshakes all around.  "That's great Mr Customer," Frank smoothly closed.  "Tim will get us the specs and a mock-up in a few days.  Just sign here."

What critical functions did Tim irresponsibly fail to provide in this all too common situation in custom programming?  Extra points if you can name more than one.  Hint: there are at least three.

Part two of the story can be found here: When techs try to comminicate with management.

9 comments
adam.howard500
adam.howard500

Well, there are lots of possible functions that I can see that may not have been provided based on this description. One thing that jumps out at me is that if you are looking at a true muti-user system with microcomputers (PCs), you have to have a network. It was not mentioned whether the customer had any PCs and/or a network. In that abscence, I'll assume they didn't. This is one of the situations that should always be mentioned as it can upset the expectations of the client if it is not. Then there is the possibility of connecting this new network with the existing DEC machine. Somebody would need to set up these network(s) for the client. I don't know whether Tim could do this or not. But if not, then it should at least be noted that this is the case and that other people would need to be brought in. Another hardware-related concern I would have is that there is the possibility that the client would be storing so much data that it wouldn't fit on a 5mb hard drive. This data analysis should be done before hardware specs are considered. Another thought I had, and it is related to data analysis, was how the client will get their existing data off of the DEC and onto these PCs. This function could be a project in and of itself in addition to the main requested system. If it needs to be done quickly, you may need two sets of programmers -- one group works on the main product, the other group works on the data conversion. That's what I can think of right now that hasn't actually been mentioned in other posts so far.

tim
tim

In the old days of CP/M and MP/M there really were no networks. This was even before PC-DOS or MS-DOS. The way it worked was to hang serial terminals off the back of the box. Yes, that issue should have been mentioned to the client. Today, limited data storage capacity like that would be a serious problem. In those days, a large database was anything over 1MB. We figured his 5MB drive would last him for a few years until the technology caught up to his storage needs. And yes, the client should have been advised of the work involved to get his existing customer list, A/R and inventory off of his timesharing system. It was probably assumed that it would all be manually re-entered. Expectations were lower in those days. All excellent points. Well thought out. Thanks Adam.

aathey
aathey

I respect the need for positive stories, and I'd find it discouraging to read nothing but doom and gloom. On the other hand, though, these can be good learning experiences for the naive and inexperienced out there, and complement the success stories well. So, as long as our host is willing to share some skeletons from his personal closet and enlighten us on some real-world blunders, I say go for it. Now, to play the named game... 1. Tim failed to give any indication of scope--the customer was asking for what sounds to be a massive enterprise-grade project, which is far and away above a one-man job. Unless said one man has 2 years and unlimited coffee. Tim had an obligation to keep the customer expectations in line, and could have salvaged the project by suggesting a partial solution that is ramped up over time. 2. This is a fine example of breaking one of my favorite adages: under-promise, over-deliver. Assuring the customer that this was a routine, "piece of cake" job would knock expectations of cost and time schedule horribly out of whack. Playing off item #1 above, this realistically two-year job would sound to the customer to be a 1-month turnkey product adaptation. No matter how capable the team was, this would be turn into a losing battle of escalating costs and time estimates, leaving one unhappy customer even if the product turned out flawless. 3...left to someone else's discretion, time to get back to earning a paycheck.

tim
tim

Yes, that was the main problem with this initial meeting. There's no way an analyst should commit to a project like that without a thorough data needs analysis and determination of reporting functions required. What should have been agreed to was authorization to create a job spec - and only a job spec - nothing more. Your second point gets at the heart of the whole story and what really happened. I won't spoil it yet, but the 'piece of cake' comment is what really got the project into trouble. It wasn't a piece of cake and the analyst should never have voiced such a comment so early in the game, especially not in front of the customer.

The Listed 'G MAN'
The Listed 'G MAN'

How about telling us something you did correctly and that had a positive outcome (instead of all this firing, broken promises, insubordination jazz)? Just a thought!

tim
tim

This one has a positive outcome. The ideas generated by willing participants may be helpful to some, especially those considering independent contract programming work.

dawgit
dawgit

Plain and simple. It wouldn't have happened around me. (geez, no wonder I place Sales People down there below the Lawyers.) Reeks of Sleeze -d

LocoLobo
LocoLobo

actually sign an agreement to purchase something that didn't exist? If he did, did he at least get a contract with all those specifics he had just outlined as hard deliverables? It sounds to me like you weren't the only naive one in the room.

tim
tim

Memory is fuzzy on that one as this was so long ago. If I recall, the agreement signed was to engage services at x dollars per hour with details of hours to be provided later.