Some Satisfaction and Success

In 2013, a large client, which we'll call Companie S., will be moving 3,000+ users into a new office; and one major part of that is what they're doing with their data processing facilities.  In general, their server crap will move from this New York office to a third party location around about the same time that the people will go from one office to another.  This company is an investment bank, which means that a large chunk of the employees actually buy and sell stocks on the major markets (e.g. NYSE).

One of the truly cool technology things right now is "thin client," which means that the monitors/keyboards/etc employed by each user are connected to a low power device which goes through the network to more serious hardware.  Normal users can accept a longer delay in screen refresh (e.g.) than trading users.  The hardware for trading users' thin clients will stay in the new office in New York while the hardware for the non-traders will go to one of the off-site data centers.  In addition to that equipment, there's a small amount of servers which have to stay with the people.

They also have a data center in New Jersey which may or not (but really will) move to a different location. 

This is a huge undertaking.  In addition to building the office and moving the people there are a ton of technology changes which are critical to making this happen.  Moving to thin client requires a lot of work; and servers will be consolidated onto blades and virtualized; and then there's the whole trading piece.  Oh, yeah, and they have to move the two data centers.

PTS was hired to explainify what I wrote in the first two paragraphs (i.e. "define the Core Processing Relocation Strategy") and to help Companie S. pick the two data centers.  I am the project manager, and I need to wow the pants off of these people so we can win the rest of the work.  (Winning the work looks good for me professionally regardless of the fact that I can't wait to find a new job.) There are two directors involved: an account manager and a project director.  These gentlemen, whom I adore, are my management support.  In addition to numerous employees and subcontractors who are providing me with different types of assistance, the leaders of five "stakeholder" teams at Companie S. report to me as it pertains to the project.

The first deliverable for this project, the strategy document, details the server-pertinent requirements for the new NY office and the two data centers.  It has to talk in detail about what's moving, how much power it needs, and how much space it needs.  It has to talk about technology trends over various spans of time and it has to account for those trends as they relate to the space and power required to make it happen.  There are a lot of moving parts.  The presentation-grade sheet in my Excel file has three or four levels of dependencies.  The bottom two levels are based on information from the client, my people, and numerous manufacturer companies such as Cisco and HP; while the top two levels are based on my analysis and professional opinion.  Those tables go into a 30-page opus.

When building something like this, there are multiple stages of review.  In my internal project schedule and resource allocation plan, I called for two points of quality assurance by the two directors.  The first one was two weeks ago; and while one of them submitted some notes they were entirely surface-level.  The other guy barely even gave me a read receipt.  But I dealt with it and my primary client contact had the first draft at the top of his inbox when he got back from his two weeks of coincidental post-baby time.  He and I ran it past some of the stakeholders before his boss came back from their headquarters office.

We scheduled a meeting with his boss and I couldn't attend in person because that was the day of my rear windshield explosion.  I was on the phone while the two directors were in the room with the two client guys.  At more than one point it was a little too evident that they hadn't actually read the thing because they were questioning basic assumptions made by both PTS and Companie S.  That frustrated me, but I held my tongue, and the meeting yielded a good number of changes, some of which were superfluous but most of which were substantive.  I spent the rest of the day making those changes and the thing went back into review by the next tier of stakeholders.

Near the end of those reviews I noticed a mistake in one of my formulas which changed some of the space requirements.  Since it was only in draft this wasn't a very big deal, but I handled it well: I identified it, got in front of it, and corrected it.  However, while I wouldn't expect anybody in the QA chain to give me pause by calling it out as a point of concern.  A comment like, "Have you validated these footages?" would have been perfect.  That's the point of QA.

As the process neared its end, we prepared to go to the last stakeholder group: Facilities.  These are the people who will manage the construction portion; and the head of that group is tightly connected to the executive board in the country where Comapnie S. is based.  This is showtime.  This is a meeting with two C-level people in a major international financial institution, and as I continued to polish the document I continued to seek input from my bosses.  I sent the final draft of the report to them in an email which's subject included, "PLEASE ACTUALLY READ AND RESPOND."  In that mail I asked them to each read the PDF extremely critically to be prepared to role play a worst case scenario of the reactions in the meeting.  This would help me to be fully prepared; and it would also familiarize each of them with the material, thus allowing anybody to speak to the report.  One of the guys read the first half on Wednesday and he was in the office Thursday.  The meeting was at 3 and we were leaving at 2:15.  He finished reading the second half (the half with the actual conclusions) at 1.  The other guy decided to go out to lunch (granted, with a customer) and not read the thing at all.

Those two items spurred my Facebook post about a lack of support from above.

HOWEVER, after the first guy finished reading the thing he had no criticisms.  I pushed him and I pushed him and he wouldn't budge: He said it was a very strong document and incredulously asked me if I thought he'd bring a weaker document in to this guy. My cynical brain said, "Yes. You've done that to me before," but my mouth said nothing.  The other guy just came along essentially to glad-hand, because as much as I love him (and I truly do) he just can't be bothered with details.  Brimming with cautious optimism, I entered the conference room.

And I was a hit.  I answered every question and could back up each answer.  The facilities guys had brought the engineers who are working on test fits of the building and my numbers matched theirs, even though they were based on a drastically different set of variables.  The tone was genial, I didn't let myself get too far into things, and at the end of the hour we weren't finished reviewing the whole document; but it was deemed unnecessary.  This facilities guy, known by people both inside and out of his organization to be a tough nut to crack, thanked me specifically and praised the report.  My guy and his boss thanked me more profusely because they were worried about this guy's reaction.  And one of the engineers, who works for a company with which we compete in many ways, went out of his way to tell me that the report seemed daunting at first but once he started reading it he found it to be quite easy to follow.

This was the best possible outcome, and I am proud.  The strategy goes into my portfolio.  Here is a link, in case you're interested; and I hope that at least a few of you will read through this thing because in addition to it being a great document it might give you some more insight into what I actually do for a living.