Lessons From A Website Overhaul Project #2: Development Phase

Following up finally after a solid month, I’m not a prolific blogger as you can tell… from my previous post (rant) about getting started with with a big website refactor, using a small internal team to do a new company website, while pulling away from contracted work. While getting this project off the ground was quite the exercise, we managed to consolidate the development team down to 4 people while containing oversight and external input to a core set of stakeholders.

I spent a lot of time doing the research that I already knew, to present and frame this argument about having a lightweight, agile team for the development phase. I found this particular post fairly helpful and interesting: https://www.smashingmagazine.com/2009/02/10-harsh-truths-about-corporate-websites/

We were assigned an unrealistic timeline of about 3 months to go from concept to completion on a huge website with large product catalog, support and informational pages and so much more, with 3 employees and a temp. A couple more hands would have been nice, but we also wanted to avoid #8 from the article posted above, or as I like to call it, “too many cooks”. We started working on our site plan in mid-may, using JIRA as a project management tool, but not in an agile way, more as a task tracker. I customized the board so that it would make sense to the rest of the team who have not done any agile training before. We set about drawing up the project scope, trying to figure out all the tasks that we would need to do, and get them on the board. I really wanted to be able to get a good estimate in but, as a team we failed to get all our tickets on the board with proper estimates. Here is what our cumulative flow for the entire project looked like.

If we had been able to scope our project out better, we would have front-loaded a lot more tasks and that diagram should have shown us burning them down. Instead as we developed our scope changed, adding new tasks along the way, which lead to some issues to timeline estimation with our stakeholders who were all about the release date, and being execs they didn’t care for or want to hear excuses. Another problem we had with this approach was that as the developer, my initial workload was up front, setting up and configuring the web server and staging website, designing a functional system within the guidelines of best practices for a Drupal 7 based CMS website.  After that, most of the work was on the content creators, the two other members of the team and our temp who turned out to be a fantastic resource with Javascript and CSS knowledge to support the content creators on the “small things” while I was freed up to continue researching and developing for this and other projects I was on.

We had some big sticking points with such a short timeline regarding feature development, of which the biggest was a product catalog and implementing a decent website search mechanism. That would definitely come back to haunt us post-release. What we ended up doing in order to achieve our deadline was stake out a set of release goals and then post-release goals. Things were going smoothly for the first two months of the project when we all had our roles to play, the workload was spread pretty evenly and we were seeing day to day advances, where the site was beginning to take shape.  But as we approached our deadline, things began to fall apart.

This brings me to the major lesson learned during the development phase, and I think this holds true for any project and it’s mostly the fault of our execs and stakeholders. They failed to assign a leadership role to the project. Three of the four people on the team seemed to work perfectly fine as a collaborative group on equal standing, that included our temp. While I felt that I was snubbed by management to not be the anointed leader of the project, I was perfectly happy to work as equals, all playing our own part.  But one person felt the need to just assume the leadership role as the project got closer to release date and it was apparently we were going to shoot well past it by another month. That person began to take on an authoritarian personality, became abrasive and started to cause drama. I can’t put my finger on it exactly, but whether it was the stress and the weight of the importance of the project  along with the unreasonable time to complete that just pushed them to this point, or if it was for personal/career gain to be able to say look at me, I was the leader of this team that did this big project… I don’t exactly know, but it was a severe detriment to moral and to actually getting the work done. It got to the point where HR had to step in and have some “talks”.

By the time we were getting near release, we wanted to be done. We also began to see the gaping holes in the product that, through our poor development preparation and then subsequent drama had accumulated, to the point where we were also not proud of our product. We were basically just at the quitting point, ready to produce a live website that was not done and wash our hands of it. All pride had been lost, to the extent that I don’t think we even wanted to attend our little launch celebration party.

The go live date was Sept. 12, 2017 and now almost two months later, still working on it. The team has split up, only me and the person who stressed out / tried to take over, continue to do meaningful work. They are doing content and I’m keeping the lights on, we’ve got a third party contractor working on a solution for fixing our product catalog… so much for getting away from the contractors eh?  Oddly, our new team of two has managed to come to terms with the drama that happened and be professional, and continue on with a good working relationship. So that’s a takeaway, as long as you can forgive and forget in a professional setting, with a little time some of those uncomfortable relationships can become workable again. I don’t think everyone on the team is back in good standing though, 2 months later I think there is still some tension between the others, but I’m all good.

I still have one more piece to write, about the entire post-release fallout, which I’ll try to get to soon.  Once again, looking back at this, the lessons here are more about people and management. For me and this blog, which I’ve tried to make a little more technical in nature, that’s a bit out of my comfort zone.  But I’m coming to terms with this truth about development and tech; that truth being – that the tech is the easy part. If there is a technical need or problem, the software already exists or the code can be written to solve it.  But no software or code in the world can manage the peripherals of a project like this; the expectations, stresses, personalities, and agendas.

Leave a Reply

Your email address will not be published.