Project management can provide some interesting paradoxes when it comes to the sequencing and designing of your project tasks. Logic plays a big role in scheduling tasks, however, other factors can come into play and alter the course of your project. In this video, Bob McGannon shares two real life stories where the logical way of doing things was not in the best interest of the project or your business.
- Project management can provide some interesting paradoxes. Take the scheduling of tasks. Typically, we're expected to sit down with our teams and determine the logical, most effective project plan. However, more often than not, other factors arise that alter the course of your project, and your logical plan goes right out the window. Here are a couple of real-life stories where the logical way of doing things was not the best way. I was managing a project to design a technical solution which required several existing systems to be integrated into a new central application.
The roll out of the solution was to be performed one customer at a time over a six month period. There were two approaches we could take as to when we would design the customer interface. The logical way was to lay out the interface as we worked through the design phase for each customer. This approach would've enabled us to only involve each client once, as we designed and implemented their solution. However, we decided it would be best to perform the interface design for all customers at the same time.
We were concerned that nuances for each customer would need to be considered up front to ensure we met all of our customers' varying needs. This approach actually increased the duration of the first customer's implementation but resulted in less rework later on. In another situation, I had a team that was rolling out new desktops for our organization. The staff getting new equipment was located in three buildings in two different cities. The logical and most cost-effective way to deploy would be to go floor by floor in one building and then proceed to the next.
However, from a customer satisfaction perspective, that wasn't the best approach. We needed to deploy by functional area. For instance, all of the engineers needed new equipment at the same time, as their computers were also getting updated graphical capabilities. If we went floor by floor, some would have new equipment, others would not, and they wouldn't be able to collaborate effectively. We decided the next group to deploy was the senior executives, as they expressed some hesitancy about the need for new desktops.
Replacing their machines early on demonstrated the value of the upgraded computers, which helped us obtain buy-in and momentum for the project. Clearly this was not the most efficient way to implement the solution from a technical perspective. However, it was the best way considering the impacts to the business. So build your most logical schedule, but be prepared to throw pieces of it out the window. While technically logical is good, we need to consider business realities when sequencing the tasks on our project.
- Identifying and managing stakeholders
- Guiding process and organizational change
- Considering a cloud-based solution
- Planning a technology project
- Assessing risks and changes
- Executing a technology project
- Addressing challenges such as conflict and changing priorities