This is the first segment in a series I will blog on about managing a library website redesign project.
Back in November, I mentioned that our library leadership has charged me with introducing project management into our library corporate culture and serving as the Project Manager on our first official “project” — a comprehensive redesign of the library website. That was almost one full year ago, and yes, our project is moving along quite well now, however we are just now wrapping up the first official stage in a formal project — the Project Initiation phase.
I know that some of you may be cringing at hearing that, after 11 months, we are just now wrapping up the first phase in this process, but let me explain.
We kicked off the project in January, half-way into an academic year plagued by furlough days imposed on us two days a month due to the state budget crisis. On top of that, the library faculty and staff involved in the project have had to juggle our redesign project responsibilities with our existing full-time job responsibilities, despite our reduced work hours. And, added into that mix, this redesign is the first time that most of my Stakeholders and Project Team have been exposed to formal project management. Yes, some of these individuals have had half-day or one-day seminars on project management…but they have never actually worked under project management principles. And although I have worked under formally managed projects in the corporate sector, this is my first venture as the Project Manager.
I have no doubt that, if this redesign were taking place a year from now while we tackled smaller projects throughout this year, we would progress at a much faster pace. But, this is the price we pay for jumping right into the fire with such a big project as our first one.
Late last week, my Stakeholders finished the first draft of our redesign requirements — a well thought out list (a realistic list, but still a “wishlist” at this point) of evidence-based decisions that will dictate our new site architecture, functionality, tone, and content. My Project Team — the web developers who will do the actual programming and design work on the new site — are reviewing the 33-page requirements document and are expected to provide us with their systems feasibility study by the end of this month.
When I started preparing for this project, I had a very tough time finding good examples of documentation that would meet our library’s needs, and also found very little write-ups about how exactly to think through these new processes. So, in hopes of helping other library or academic technology professionals in a similar situation, I will share our documentation, as well as discuss the roles, methodologies and rationales involved in our project processes. So far these processes have included defining our:
- Problem Statement (completed): The problem(s) this redesign project is expected to solve.
- Needs Assessment Report (completed): The data and analysis that is driving our evidence-based redesign.
- Business Requirements (1st draft completed): The description of what our redesigned site should do in terms of design, functionality, performance, and usability.
- Feasibility Study (in progress): Whether or not we have the infrastructure and expertise necessary to fulfill the operational and technological goals proposed in our design requirements.
In the meantime, if you have any immediate questions, please feel free to leave a comment below or to contact me.