Four months ago, I began my new job. I quickly realized that I was going to have to hit the ground running. The guy I was replacing was heading to a new position the next week. Not only was he moving to a new team, but he was physically moving to a new building. I had a week to learn everything I needed to know.
My team would consist of two members. I would be the business analyst, and the other team member was the developer (programmer). We were building a system to replace the company’s financial reconciliation system for the investment accounting area. As someone who was accustomed to large project teams (often a dozen or more people), this was a big change.
Early in the week, my boss spent a half hour with me and another new hire, giving us the basics of investment accounting. Although I have a degree in accounting, I hadn’t used that knowledge in my previous job, and it had gotten a bit rusty in the twenty years since I had last sat in a classroom. The basics came back pretty quickly, though. It was like riding a bike – you don’t forget.
The first week was spent acquiring the access and software I would need, as well as spending time with the outgoing business analyst and the developer I’d be working with. The learning sessions were helpful, but it seemed like I was missing a lot of context. I finally asked the BA if there was any additional information, such as meeting notes from discussions with the business partners. Yes, there were meeting notes. (Why hadn’t he shared them right away? I have no idea.) These helped provide a bit of context, but it became obvious that the high level requirements that had been gathered to this point didn’t capture the whole story.
In my second week, I requested Visual Studio 6 for my workstation. (Yep, the current system was that old). I was hoping that the existing code would be well-documented. Not exactly. The areas that had been updated recently were pretty well documented. Other areas had very limited comments, if any. This was going to be an interesting challenge.
The system was heavily dependent on database stored procedures. I was aware of the existence of stored procedures, but had never actually used them. In my previous job, I had done occasional coding work, but even in those cases, I always interacted with an object that did all the database interactions – I had rarely written code that had interacted directly with the database. Well, it was time to learn. Once again, the stored procedures weren’t particular well documented, although recently updated ones were better.
I spent several weeks poring through the existing code, trying to reverse engineer the existing process. I was doing this mostly on my own, as my developer had his hands full with other tasks. He was always helpful when I had technical questions, though.
By the time I was ready to engage the business area to drive out detailed requirements, I had created quite a few Visio diagrams detailing the process. These were helpful in explaining things to the business partners and my developer. At this point, I have a better understanding of the workings of the current system than the developer or the business partners, due to being immersed in it for months.
I had been warned that the business partners might be somewhat difficult to work with, mostly because of frustration at the limited progress the project had made. I didn’t let this discourage me, and I went into the sessions with the positive attitude. My attitude was infectious. Even though I was a contract employee, I think the business partners realized that I wanted to help build a solution that was the best fit for their needs.
We’re mostly through the requirements process at this point. We still have a few points to drive out further, but we have most of the system requirements hammered out. My developer is beginning work on screens and some of the basic logics. Although the project is technically using a waterfall method, I’ll be pushing it to a more iterative approach. There’s a lot of complexity in the project, and handing off the entire system for user testing at once would be a recipe for disaster. I’m confident that the business partners will change their minds on a few things, and it’ll be better to know those changes as early in the process as possible.
The job is a contract to hire position, with the contract set to expire in late September. My boss isn’t sure he’ll have budget to hire me at that point, but I’m very confident that the contract will be renewed. I’ve had discussions with my recruiter to push my rate up a bit for the second contract. When I initially negotiated, I knew that I was probably leaving a few dollars on the table, but I was more interested in making sure I got the gig, so that I could get a foot in the door at a leading company in the area. Also, after twenty years with the same company, I wasn’t sure how my skills would translate to another company. At this point, it’s obvious they translate very well. I’ve gained a reputation for having a willingness and ability to dive into things and figure out how systems are working, as well as a willingness to assist with other projects, and an ability to get along with everyone on the team.
So far, so good. If the company offers my full-time employment at a salary that matched the salary at my previous employer, I’d definitely take it. It’s interesting work, and it’s a great work environment, with a boss and co-workers who are easy to get along with.