Project Management: Bad Graph - PM

I take full responsibility for the above graph. Like any large project (4 1/2 years of development) there were lots of various egos and timelines at work, but as the Product Manager it was my job to mediate and manage such things, which i failed to. The Site application went live and we slowly watched as it crashed in a hundreds of little ways that we thought we had protected against. However, within a month we turned the above graph to the below graph, and we probably accomplished more in the 6 weeks in terms of development then we had in the previous 4 years. Ironically, the best thing for the application as a whole was this initial disaster. It turned to this:

then this:

What changed

1. Total Focus on the Team's Part

The Development, QA, and Product team were all juggling different projects throughout the 4 years, none focused on this project alone. There were branches of code that had been developed two years ago that never had been touched for the new application, and nobody bothered to test why it was there (it was important - though engineering did tell us they checked it - nobody likes reviewing old, un-annotated code).

When the app failed, all of us got together and focused in a way that I wouldn't have believed months ago. Sprints became daily, bosses let me make quick decisions, releases were weekly, QA was broken into pieces to focus on different parts of the app, webops became very involved with release, and I got on the phone with all the clients in 16 timezones daily to prioritize, review, and of course apologize for anything that broke and hurt business. This last part was horrible but essential, since I had to make sure business kept going. In a two-week period I probably talked to 260 people (in groups), most of whom were not happy with me. But by doing this it gave them all a very clear face with which to talk, and most importantly it gave the development team clear small goals. When the clients saw how quickly we were addressing all their complaints, hitting release dates, and adding features as well, their anger slowly turned silent, and they started understand and respecting the new system, and we got lots of thank yous!

2. Direct Control

Before the crash, so much time was spent on release dates, budget and design approvals, rather than actual project management itself, that this confusion of focus made the dev and design ambivalent to the project as a whole, nor did they believe each other. Lead engineers would scrap scrums, because they didn't want to spend their teams time on something they didn't see have value, and the design teams were exhausted making mock-ups around color and font versus usability. When the crash came, we focused. I took direct control of the scrum and priorities from the TPM, nobody had the luxury of talking design or dev team focus their where was just priorities, user feed back, QA A/B testing and release. Politics went away.

3. Dev + Product Teams

Accomplished almost a complete rebuild of most core functionality, it was incredible, time management issues went away and the devs were allowed to solve problems locally and submit it to peer review within a day versus weeks. More importantly, we moved the product (front end team) to work directly with development, so CSS/JS work could be integrated with the JSP, this moved the teams to work in tandem to divided scums up between.

This was a great learning experience, however, as we resolved everything the inevitable entropy of working with big corporate IT has became apparent again, and the phrase "product development and usability" has left the conversation in the other projects that are years in development. Sigh.

Here's the complete 3-month release period: