Part 1 | Part 2 | Part 3

The one thing our project didn’t have was a dedicated business analyst because the project manager was supposed to fill that role.  This was less than ideal, and in the end, cost the project in several ways.

At the start of the project, the PMs role was defined as:

• Responsible for overall delivery of the project
• Manage the release plan, Truth Plan, Project Log, Change Requests
• Regularly communicate project status to stakeholders
• Responsible for establishing project Cadence (scrums, status, UATs, etc)
• Work w/ SME to develop Use Case documents to be passed to developers.

Even though the PM was supposed to be the BA and develop use cases, our requirements almost always consisted of a “wireframe” and one or two sentences in our issue tracker. 

The process normally went something like this: the UI specialist to sit down with the client and the PM and have brain-storming sessions about the functionality.  The PM would take copious notes and the UI designer would make sketches of the proposed UI.  After the meetings, the PM would more likely than not scan his notes and upload them to our wiki and then forget about them.  The UI designer would spend days, sometimes weeks making “wireframes” from his sketches.  Most of the times he’d make his wireframes “work” using a variety of hacks and then he’d present them to the client.  What really sucked about this is that much of the time, the client would say something like, “cool, it’s almost working.”  :-\

In the whole scheme of things, there were probably 5 or 6 large pieces of functionality within the system, but by the time I left the project, we only had 2 use cases.  TWO.  That’s it.  Given the way the consulting company I was working for operated (or at least claimed to operate), we should have a few more than two.

From the day I took over as tech lead up until about a week before the project was done, I repeatedly asked for more use cases.  It’s damn near impossible to develop good software without knowing exactly what you’re supposed to be developing.  One or two sentences and a screenshot are far cry from a well written use case.  The lack of requirements and use cases didn’t just frustrate me – during the course of the project, there were 2-3 other developers involved and they let me know pretty bluntly that we NEEDED better requirements and more use cases.  I knew it.  they knew it, but unfortunately the PM didn’t see the importance.  I brought the topic up during almost every conversation I had with the PM.  At one point I even escalated the issue to the manager overseeing the project, but for whatever reason, it didn’t help.

One of the things I did was to tell the UI guy that he could no longer show the client the wireframes without passing them by me first.  Early on, before I intervened, he introduced some elements into the UI that were actually pretty difficult to implement and I wanted to make sure these things were caught before the client saw them and we were committed.

As I’ve mentioned, we were behind schedule almost from the very beginning of the project.  Behind schedule and under-staffed.  Behind schedule, under-staffed and under a LOT of pressure to get things done.  Even with the problems I’ve discussed, I was still very optimistic that with enough effort we could nail this project.  I was so optimistic that I worked 7 days a week for several weeks.  Most days I worked around 12 hours, but some were longer than others.  During that time, I only took a couple days off; one day to hang out with a friend in South Bend, IN  and the other to go to the Dayton-Cinci Code Camp.  The day I got back from the code camp (Sunday), I pulled an all-nighter to implement a piece of functionality that absolutely had to be in place by Monday.  It was not something I’d recommend to anyone, although I know some people enjoy working frequent all-nighters. 

It was shortly after that coding marathon that Will joined the team.  I didn’t know Will, but given who he worked with, I had every confidence that he could help us get ahead of the curve.  In the few weeks he was on the team, I went from overworked and panicked to less overworked and less panicked.  He helped me realize that in the whole scheme of things, the success or failure of the project really didn’t matter as long as I did the best that I could do in a normal 40-hour week.  Shortly after he joined the project, I had a great conversation with Dave Donaldson about my role on the project (I was never formally told what my role as tech lead involved until pretty late in the project) near the end of the project.  Between this conversation and almost daily talks with Will, I started to pull out of the “hero” mode and get my life back.  Life really is too short to spend every waking hour worrying about things that are out of your control and Dave confirmed that many of the issues were in fact out of my control.

In fact, one instance of taking my life back resulted in quite a blow-up with the PM.  A few weeks before Memorial Day, he took a 5-day weekend to go on a fishing trip while the other developers and I plugged on and tried to whittle our issue / feature request list down.  Not a big deal, right?  Everyone is entitled to some time off and I certainly didn’t begrudge him a little time off with his friends.  Fast forward to our 11am scrum on the Thursday before Memorial Day.   By this time, Will had rolled off the project due to monetary constraints, so it was down to John and I.  Anyway, the PM was filling us in on a meeting he’d had the day before with the client and a group of investors.  The gist of that meeting is that the client and investors “absolutely had to have” some features implemented by the following Wednesday at 3pm for a demo they were doing.

Did I mention this request was made the day before the start of a long weekend?  When he laid out the tasks that needed to be done, it was something like 40-hours of tasks to be completed over 5 days with 4 of those over the long weekend.  The conversation went something like this:

PM: “You guys need to get this stuff done for next Wednesday.”
Me: “but it’s a long holiday weekend.”
PM: “This stuff needs to be done.”
Me: “It’s a long weekend and I don’t plan on working.”
John: “I didn’t plan on working either.”
PM: “But this stuff needs to be done.”
Me: “It’s a holiday weekend and I have no desire to spend any of it working.”

After 10 minutes of back-and-forth on the subject, it came down to John and I saying we might work a little, but there was no guarantee that we would.  After all, we were given almost no notice, we had been working killer hours for about 2 months straight with NO overtime being paid AND it was long holiday weekend.   The PM seemed cool with that during the phone call, but not too long after that, he sent an email adding more tasks to the list — these new tasks brought the total up to 70+ hours to be completed by the following Wednesday.  It was at this point that I did something I normally don’t do.  I CC’ d my reply to a manager who was very cool about the whole matter.  He basically told the PM that he could NOT expect us to work over the holiday weekend with only a days notice.  Woohoo!  So, once again, we left it at “we’ll work if we have nothing else going on”.  Again, he seemed ok with it.

That was the most glorious, stress-free weekend I had experienced in a long time.  I played some WoW, I hung out with my family, I watched TV, but I didn’t work.  I didn’t even check email.  John pretty much followed suit and just enjoyed himself.

Fast forward to our scrum on Tuesday:

PM: “Well, I’m disappointed that you guys didn’t work that much over the weekend.”
Me: “I enjoyed myself.  It was a nice break.”
PM: “Ok, so what can we get done for tomorrow’s demo?”

It was at this point that things started to fall apart.  One of my jobs as tech lead was to estimate tasks and I learned early on that given our vague requirements I had to estimate high.  Out of all the tasks they wanted for Wednesday, only a couple were less than 8 hours.

Me: “We’ll get done what we can get done.”
PM: “Ok, so what can we get done by tomorrow at 3pm?”
Me: “We’ll get done what we can get done.”
PM: “Ok, so what can we get done by tomorrow at 3?”

Are you seeing the pattern?   In all seriousness, what other answer could I give?  We were having this phone call at 11am on Tuesday.  We had a list of tasks that were all at least 8 hours in duration and John and I were NOT going to kill ourselves to get this stuff done.  The fact is, WE didn’t commit to the Wednesday date.  The PM did assuming we’d work all weekend.  This was his problem, not ours and the manager was backing us up.

Me: “Look, we have X number of tasks, only 2 of which are under 8 hours in duration.  We’ll get done what we can get done.”
PM: “You’re being very non-committal.”

It was at this point that I lost my cool.  I won’t repeat what I actually said, but I will say my wife was in the room and she stopped doing whatever it was she was doing and looked at me like “OMG, I can’t believe you just said that.”  The phone line went strangely quiet for a minute or two.   In the end, he had to deliver the news to the client that they wouldn’t have most of the features he committed us to.

We had 3 weeks left on the project and there was no chance we were going to continue on the project due to financial constraints.  The PM wasn’t giving us good requirements, he wasn’t pushing back on the client when needed — in fact, he was siding with the client almost 100% of the time — and the fact is, I was physically tired, even after the 4-day weekend.  Week after week of minimal requirements, crazy deadlines and continuous demos had drained me of remaining “hero” I had left.

The last 3 weeks of the project were actually pretty quiet.  John and I did our best to implement the remaining key features and make the app more robust.  My final job was to assist the person taking over the project.  This was a guy I had interviewed for the team but had turned down due to him having NO experience with anything .NET or SQL Server.  Well, since he was a good friend of the PM, the PM convinced the client to hire him to handle the pilot and the rest as they say is history.   The 15th of June was a beautiful day — like a huge weight was lifted from my shoulders.  I honestly didn’t look back until I had a post-mortem with the manager a few weeks later.

Did I make mistakes?  Absolutely?  Did the PM make mistakes?  yep.  Did the consulting company we worked for make mistakes?  Uh huh.  Same with the client.  My final post of this series will talk about the mistakes we all made and the lessons I learned.

Wow, this was a long post.  Probably really boring for most people.  If so, I’m sorry.   I’ll try to post more interesting stuff in the very near future.