Mike Staley, Project Mayhem
Jason Lindquist, software programmer at Manzanita Systems in Poway CA.
I interviewed him asking about a project he worked on that was successful, and one that was on unsuccessful. His insights were very helpful and I think that he offered some important insight from the “inside.”
The first experience he told me about was a project he worked on in which he was redesigning a computing appliance system that displays advertisements on TV music stations. It was a P.C. that was meant to do only one thing, and he and another guy in Florida (Jim) were working on the project together. Jason was doing the software aspect of the project while Jim was doing the hardware aspect of it. It would take the advertisement graphic, and insert it right onto the TV. It was an already existing product, and his task was to basically re invent it, because the PC hardware was built on parts that you can’t find anymore. It also needed a new interface card. Jason said that he had a pretty good definition of what the old product was, and what the new version of the product needed to be.
The hardware part was basically done, but the software was really what needed to be completed, as well as some different parts of the hardware that needed to be finished up. One of the difficult parts was working with someone who was in Florida, so Jason typically had to start working at 5 AM so they could talk about the work they were doing. He also needed to catch up on the type of programming Jim was doing, so that each person could be familiar with what the other was doing.
From a project management perspective, there were daily conference calls and screen sharing, to figure out what the card needed to do within its capabilities. Jim and Jason used an iterative approach, saying “OK we have this working, let’s move onto the next thing.” And of course when things weren’t working, they had to figure out how to fix it. Jason also said that debugging would have been much easier if the two were looking over each others’ shoulders. Each person had enough of a background in what the other person was doing that explaining the problems was doable, and the debugging process wasn’t simply explaining what the code meant and what is was supposed to do. The project ended as a success, with the clients being happy, and not changing requirements on them.
Another project that Jason worked on that didn’t go so well was at Qualcomm. Jason was working on a project where Qualcomm had a way of sending performance information from the phones that Qualcomm was producing to PC’s. The method they had of sending the information was good enough when it was first written, but it drastically needed to be rewritten as the phone got more complicated, and as it needed to send even more information. He and a partner came up with a way of sending that information, but they had some major project management problems.
The equipment that Jason needed to test on was not made available to him, because Qualcomm felt that the resources Jason would have needed would be better used elsewhere. It was a classic case of management not understanding the problem, and not caring to do what it took to give Jason what he needed to fix the problem. Somebody else was already using the equipment he needed, so his superiors said that he needed to handout the work he had done to them. Because someone else was handling Jason’s part of the project after he had finished his work with the phone, the project would take much longer than it should have.
The people to whom Jason gave his work had plenty of other things to do, and had very little vested interest in completing Jason’s project. Worse yet, Jason’s management didn’t have the authority to tell the other group to do anything, showing corporate bureaucracy. All Jason and Jason’s team could do was “hey when you guys get to this can you please try it out?” which obviously did not yield very many results.
Another problem that Jason ran into was a function of corporate bureaucracy, where Jason and his team were not allowed access to the software that would tell him if the work he had done was successful or not. The higher ups were basically saying, “if it doesn’t work someone will tell you what to fix.” The project ended in the work Jason did being scratched, and Jason’s team had to start over again.
Kim Wasung, IT Professional for Cartronics in San Diego, CA.
One of Kim’s first experiences with software development and project management was working with CA-Unicenter, on a project that allowed companies to keep track of what was going on with their software and their servers. Kim installed that software on many different company’s systems. One of the more challenging projects that he worked on was when he had to install CA-Unicenter under the partnership of Microsoft and Netscape. He said that there was so much bureaucracy that it was hard to do anything without going through 3 different people. One of the challenging things about the project, he said, was simply the fact that there had been so few attempts to do something similar in the past, so estimating the amount of time it would take was nearly impossible.
In order to estimate the amount of time the installation would take, they broke it down into chunks, and wanted to complete one chunk before moving onto the next. Kim’s team had to constantly monitor the systems that were being installed, because if installed incorrectly going back to fix it was close to impossible, and would delay the completion of the project by weeks, if not months. One of the things that I liked about the approach they took was that they would have someone or a team with fresh eyes come look at their work when they were stuck. This would allow the team to step back and relax a little bit, and also allowed the new team to maybe see something that Kim and his team were not able to see. He said doing this actually helped increase the efficiency of the project.
One of Kim’s other projects was “asset management” so that they could record where the companies had hardware and software located, so that if something went wrong there was a record or a backlog of where all the associated hardware was, as well as the associated software. Kim said that project took two years because there was so much physical amounts of work to find out where the data was. One of the most grueling tasks was just to figure out where all of the hardware was, as well as the software because the company he was working for did not have very good inventory records, and so he had to spend much of his time on the phone, calling different people to figure out the location of the information he needed. He said sometimes he would have to spend a week just figuring out where a piece of equipment was. From a project management point of view, he said that he was not given the resources he needed to succeed.
Another one of the projects that Kim worked on was ensuring that all the software his client had would not misfunction when the clock struck the year two thousand. Apparently (this was something of which I was not aware) there were plenty of concerns about Y2K coming, and software acting weird because of the year two thousand. I guess Kim’s company was concerned that time stamps would be off for the software products that they were using, and that payroll would be much higher than it should have been.
Basically what Kim had to do for this project was trick the computers into thinking it was already the year two thousand, just to get an idea of what would happen. He was basically testing the theory that nothing would happen. He said he used a very iterative approach, because it was essentially the same process on each different software platform that he was using. Companies put millions of dollars into making sure that things would not go wrong come the year two thousand, and according to Kim there were no major problems.
One of the problems that he had from a project management point of view was again dealing with bureaucracy when it came to testing. There was some equipment that he needed to use for testing, but I guess the company was apprehensive about giving him the access he needed because someone else was already using the equipment. One of the reasons that the project did end up going well thought, was that the product produced to test if Y2K would be a big deal was very well written, and had good processes for testing the software. The requirements were also very well defined, and so really the biggest task for Kim was just following the schedule that was outlined for him. He also had to report to upper management on a bi weekly basis about the progress being made.
One of the last projects that Kim worked on was remote application management for Sony, and his job was to make sure that things were running 99.9% of the time. He said his management worked him too much.
No comments:
Post a Comment