Change is difficult and projects are no exception. Some of the stats shared in by Knolscape (2013) were quite surprising, only around 25% percent of new product projects actually make it to market or 31% of IT projects are canceled before being completed. My team recently participated in large project transitioning to a new web conferencing tool and I’m happy to share it has been mostly successful. The stakeholders for this project were potentially all faculty, staff and students tied to our institution. The tone of our project was well captured by Conway et. al. (2017), a project, innovation or change won’t necessarily create a huge impact on it’s stakeholders. That is to say, in this project’s context, we already had the technologies and processes that fit our requirements and it’s replacement would fall roughly into the same range of capabilities. In hindsight of our project’s completion, there was still great benefits to the users and administrative processes with this project, but these were highly dependent on the service we chose and weren’t necessarily the primary focus.
If compared to the PMBOK 10 knowledge areas shared by Watt (2014), the initiating concern of our web conferencing project was managing cost. During COVID19, the use and demand of web conferencing definitely increased and with our web conferencing contract ending it was important to review other options. Our current service provider drastically increased prices to continue our contract which made continued use of the service unlikely. Switching services required a lot of time commitment beyond the technical implementation of the new web conferencing tool. A couple items my team was responsible for were creating new support materials/workshops and developing an account creation process. We were able to collect relevant information from the vendors, other institutions already using the web conferencing tool and utilizing internal expertise. A benefit of this web conferencing project occurring during COVID19, almost all stakeholders had recently used a similar service and were familiar with core functionality. One strategy we implemented early in the project was to include a vast range of stakeholders to test the new web conferencing tool immediately after we selected one. This provided great guidance in our tasks and capturing potential issues that may not have been obvious when first approaching the project.
With potential issues in mind, our web conferencing project definitely had barriers. Specifically in the aspects of integrating into existing systems and accounts posed a challenge that is continually being worked on beyond the project. As Conway et. al. (2017) described, supporting changes in complex environments requires flexibility as a seemingly static project are almost always dynamic. What was initially evaluated as a simple step in implementation, ballooned into one of the larger issues that needed to be addressed. Luckily to combat these type of hiccups, there was a long enough grace period where both services were available simultaneously which really alleviated time pressure and minimized stakeholder impact. In any future system transitions I would try to maintain this strategy to ease users into the change and provide a backup if things go wrong early in the project.
I would consider our project a success and any barriers highlighted items beyond the scope of this project we may be able to work on soon. An additional project is already planned and will be commencing soon to address some better integration solutions. Ideally this could have been done all together, but the reality of budgets, employee time and other obligations created the need for separated projects. As long as we strive for continual learning and improvement, I’m confident we will continue to deliver great results with projects.
References
Conway, R., Masters, J., & Thorold, J., (2017). From design thinking to systems change: How to invest in innovation for social impact. Royal Society of Arts, Action and Research Centre.
Knolscape. (2013). Introduction to Project Management. Youtube. https://www.youtube.com/watch?v=BOU1YP5NZVA
Watt, A. (2014). Project Management. Victoria, BC: BCcampus. https://opentextbc.ca/projectmanagement/
Thanks for describing a very tangible and successful project. It was great to hear that you were able to implement and get early feedback from users, and as an instructor, I can attest that the move was pretty seamless and I had great support from the team in integrating the new system into Moodle. From your perspective how will you evaluate success? What kinds of measures does your team look for to determine if a new implementation is going well (or if not how do you address that?).
Evaluating success in this project context had a couple success indicators I’ve personally noticed and I know there are more beyond my involvement. One strategy was to create a test environment to conduct user acceptance testing to confirm the implementation met the outlined project requirements. Requirements for the implementation are determined by numerous sources such as IT, leadership, laws, user requests and learning center staff. Additionally we closely monitored the number of support tickets/emails we receive regarding the implementation. Our support ticketing system is setup for quick graphics to identify reoccurring issues for us to focus on. Finally offering pre-emptive and continued workshops and monitoring enrollment helps us keep connected with stakeholder’s experiences and if there is some aspect that could be adjusted to better support them.
Hi Zac,
Thanks for sharing your strategies – the quick graphics option to identify recurring issues sounds like a great tool to assess how things are going. Additionally monitoring feedback and workshop attendance sounds like a great way to plan for the kinds of supports that are needed.
Hi Zac,
It’s interesting to read analysis of a change initiative from a facilitator’s perspective that we as students participated in from a user perspective – almost a bit surreal to see these perspectives collide objectively! I am trying to reconcile the implementation stage of project management and the prototype then testing stages of the design process. Similar to your example, my organization tested some different tools for instant messaging then settled on our tool of choice and piloted it with a select group. At a future time, we will fully mandate its use across the full organization.
In my mind, the pilot and full roll-out are both part of implementation by Watts’ definition (2014), but I can’t quite decide whether piloting with a test group is still within prototype, or if it’s within testing in design thinking (Baker III & Moukhliss, 2020). Perhaps project management and design thinking stages simply don’t fully align.
Any thoughts on this?
Thanks,
Alisha
Baker III, F. W., & Moukhliss, S. (2020). Concretising Design Thinking: A Content Analysis of Systematic and Extended Literature Reviews on Design Thinking and Human‐Centred Design. Review of Education, 8(1), 305-333.
Watt, A. (2014). Project Management. Victoria, BC: BCcampus.
Hi Alisha,
Thanks for your comments. From my perspective, piloting with a test group is more aligned within prototyping and testing within design thinking. I generally believe this because in practice, test environments are rarely setup in permanent configurations (network, service, licenses, user interface) and have not gone through proper quality assurance testing. The amount of work and risk considerations from test group to full organizational deployment are quite considerable in most cases I’ve experienced personally. So I agree there may be some misalignment, especially in specific contexts, when comparing PMBOK phases with design thinking. – Zac