Knowing When to Change Project Direction – A Case Study

Knowing When to Change Project Direction – A Case Study

There are times when the direction of a project needs to change. Taking corrective action at the right time demonstrates good management practices and not a sign of failed project assumptions and decisions. Making change could be the pivotal step allowing new information to be considered which very well could lead to the success of a project. The inability to recognize when change is necessary may indeed result in a failed project. Once you have identified that the peg is square, you need to stop forcing it into the round hole.

Getting on the same page

 While working on a consulting engagement for a domestic company acquired by a similar sized global organization one of my many projects was the oversight of a new global email system implementation. The original objective was to consolidate the email systems of several entities that were brought together through a series of mergers and acquisitions. The existing systems did not share common calendaring or resourcing making it difficult to identify who was available and how to reach them. Since the new organization would be rebranded all email addresses would be changing.

 This provided the opportunity to bring everyone together onto a single mail system but it also revealed some interesting dependencies on how the email systems were being used and integrated with other applications. Aside from the single email system objective the organization was striving for a more simplified and cost effective solution. They envisioned a future where a cloud based solution would remove the need to maintain desktop applications (software installation, patches, and license management), local storage and hardware maintenance could be eliminated and overall cost savings achieved.

 The environment consisted of desktop and cloud based systems - private and public, inconsistency in management and maintenance practices, third party applications and processes that leveraged the mail systems. The project moved forward focused only on per user account and maintenance costs. The clear front runner was a cloud solution to replace the on premise integrated email and the smaller collection of cloud implementations. The losing option was an expansion of the existing on premise application to areas not currently on the common platform. This option when coupled with the maintenance cost estimates was slightly more expensive than the cloud option.

Signing the contract

 Contracts were signed based on the assumed number of accounts needed to support the current headcount with some overhead. It should have been easy but right from the start the team failed to identify how devices connected to the new email would be recognized. The existing system was only concerned about human users and had the ability to connect an unlimited number of devices with no additional license costs. It also had the ability to support email groups without adding additional licenses.

Apples and Oranges

 Comparing the current to the proposed system turned out to be an apples to oranges comparison because devices such as printers, copiers and fax machines were considered by the cloud solution as a licensed device as were email groups. This discovery would increase the required count of licenses by more than 40%. Unfortunately the great per license pricing existed only with the original contract signing and scaling up the order weeks later would come with little discount.

 The decision was to move forward with the added licenses or eat the cost of the cloud email contract and stay with the current solution. The cloud solution was no longer the most cost effective and it was now presenting unexpected connection issues with hardware and it impacted the organization’s ability to create email groups as needed.

Should we pause?

 At this point a project hold should have been implemented with two actions: 1) the exploring of voiding the contract with penalty and 2) a deep dive into the full integration of the new email with the existing landscape to see if other unknown issues would arise. A decision was made to press forward, to pay for the added licenses without discount and to not expend any efforts exploring other potential issues.

 Not taking the time to fully assess the integration led to yet another major discovery. The new telecommunications system that was being installed was considered only with the existing email platform. A separate team was working on that and there was a lack of visibility between projects. The new telco system would integrate smartly to the existing email routing voice calls and providing many services including call screening, voice mail storage on the email servers, and user notifications. The new email system could not support it at all.

The rest of the story

 In the end the company continued with the cloud solution, the cost impact was nearly double the original contract and the valued functionality tying the telco to the email was unrealized. In hindsight the total spend to incrementally purchase user seats for the on premise solution, pay the maintenance and to eat the original cost of the cloud option without implementation would have cost less and provided the telco to email connection. Sometimes you just need to know when to change project direction.

What’s Next?

 In your professional career you should strive to find the best fitting opportunity. It may be a long term direct opportunity or it may be short duration contract roles. It could very well be a combination of the two driven by your needs or factors beyond your control. In the next installment I’ll talk about both options.

 To those of you who take the time to read my efforts I sincerely thank you. I would be remiss if I didn’t remind you that this is a two-way conversation so put your comments in and let’s have a volley of ideas, so we all continue our intellectual growth.

 Mr. Gray is a seasoned business strategist experienced in PMO stand up, business transformation, process development, and best practice guidance. He has developed industry-leading methods for staff modeling, project deployment, financial performance, onboarding, and business readiness. Mr. Gray is a problem solver at heart, a sharer of knowledge by choice. He has authored more than ninety thought provoking articles which are all available on Linked-In.

If Mr. Gray makes you think then he considers the effort worthwhile.

Your PMI Guy can be found on LinkedIn at: https://www.dhirubhai.net/in/yourpmiguy/

And on Twitter at: https://twitter.com/YourPMIGuy