Impossible deadline? Stupid contract? Time to bail

From the get-go the project was problematic, and after a while, it wasn't worth the hassles

quitting time leave out the door businessman
Credit: flickr/woodleywonderworks

During my programming career, I have been afforded the luxury of working in many companies across varied industries and with a multitude of architectures. But sometimes, bad experiences can help you understand your personal limits and when it’s time to run for the door.

I was working as an architect at a consulting firm that bid on and won a contract to build a public job site for a client. It turned out that we could have used that early on ourselves to find qualified developers and perhaps a magician or two to get this project done on time and on budget.

The first meeting was ominous. Our team leader said up front that there were major technical problems and it'd be difficult to deliver in the time frame. We had to wonder why the client’s request for proposal had been so unrealistic to begin with and why our firm had bid on such a project. Nevertheless, here we were.

I felt up to the challenge -- until I got my hands on the proposal and saw what was expected. It was obvious we were in worse trouble than I’d even imagined.

What was in that RFP again?

The project was quoted without any security considerations, converting all screens from a heavily patched legacy app to a shiny modern architecture. Modifications would be needed throughout. Plus, the technology required to convert the legacy system to a different architectural platform was new to the team, so we’d have to get up to speed. Finally, the quote to complete the project was a highly unrealistic four months.

We asked our management for extensions to the deadline, which was denied. On top of all of this, the client’s team was unionized. The union rules expected a few of the developers to be offsite due to facility seating issues and to remotely access the environment to do their work.

However, there was no remote connectivity configured at this point, and the tools provided to the team didn’t have enough licenses. It would be tough to simply get the work done.

In spite of all the challenges, we kept marching on. Once I defined the architecture and began creating the design, it was clear that my job would also involve training, mentoring, and acting as tech support every day. I enjoy working as an architect that swings a hammer, so to speak, keeping my hands in the code. But on this gig, I needed a nail gun.

The client’s lead and I realized early on that we had to meet daily. The client didn’t have very much agile experience, but I was able to set up parameters we could work in to make progress. However, it was tough even to get the client's team to show up to meetings, and when the group came in, we had to ask extremely direct questions in order to get any feedback. It felt like we were speaking different languages.

A legacy system by any other name

The legacy system was so large and on such an outdated version of the vendor’s application that no one knew how to even look at the source to do any conversion. Eventually, one of the original developers was contacted and started to assist. It was a small step in the right direction.

Finally, we started working on the conversion, and a few of the 170 screens converted. We were starting to feel like we were making progress, albeit not fast enough, when another obstacle came up: The client’s management wanted us to review the security system.

Hold the phone -- the RFP never stated security changes were needed. This left turn took us down a huge detour on determining how to migrate from the old security to the new.

Then the client’s management decided the project wasn’t going the way it wanted and stepped in “to help.” Awesome! More time wasted with no decisions or deliverables to show for it.

I eventually talked to the client’s original architect and gained some insight on expectations and the end state of this system. Between him and the lead, I took away a message: “We knew no one could even do this. It took us six months to get to the position we are with the security model, and that was only the start of it.” Great -- another boost of confidence to our already deteriorating mind-set.

Enough is enough

The countdown continued and three months had passed, four or five screens were under way, and we only had maybe a month left with 160 screens remaining. The security was not complete. Management had to face the fact that we were sinking and wouldn’t meet the deadline.

I had never bailed before a project was complete but this time I did -- I’d had enough. Fortunately, a staff member took over for me, and I later found out that the project was extended another nine months and reached a level of success, which was good to learn, even if it was nine months too long for me.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.