Mike FrenetteManager, IT PMO| Halifax Water (retired)Halifax, Nova Scotia, Canada
You run the Project Management Office for a manufacturing company. A senior manager in a line department has been to a conference and attended a demonstration of a software tool she says will solve all of her problems. She asks you to arrange to purchase it and have it installed by the end of the fiscal year in 6 months time. She reports to a company director known to fully support his staff, but also known as a bit of a bull dog if he doesn't get his own way.
Ask for the formal written authorization/directive. Just because someone is a senior manager or works for an aggressive director doesn't mean they have unlimited authority. Finance, IT Security, and other branches of the company may require input on any non-standard software purchases and usage. Make sure you understand the rules of your own organization and that the request complies with those rules.
I'd agree with Keith's recommendation to ensure there is appropriate formal authorization provided first. Beyond that, it comes down to the mandate for your PMO - assuming it is NOT responsible for vetting tools, that responsibility would either belong to a different department or be delegated to each department head. If the former, I'd consult with the appropriate folks in the gatekeeping department before getting things rolling. And if the requirement is to purchase & install it, that might be feasible in a half year assuming a vanilla implementation and a reasonable procurement process. If not, do sufficient legwork to substantiate the recommendation for a longer timeline.
Or in short "it depends" :-)
Kiron Saving Changes...
Mike FrenetteManager, IT PMO| Halifax Water (retired)Halifax, Nova Scotia, Canada
I have an opinion on this, of course, that I will share once a few more people answer. "It depends" is always true, but there are certain tenets they should not be ignored when it comes to any organization engaged in "Digital Transformation". Saving Changes...
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Mike, I agree with the points raised by Kiron and Keith. However, before we move forward, I would first recommend gathering thorough details to assess the tool’s suitability for the PMO’s needs. Specifically, we would need to build a mini business case, that includes the following key areas:
1) Budget: A clear understanding of the total cost, including licensing, implementation, and ongoing support costs.
2) Technical Details: How the tool will integrate with our existing systems and infrastructure, and any technical requirements or constraints.
3) Vendor Information: A thorough assessment of the vendor’s reputation, support services, and implementation track record.
4) Stakeholder Buy-In: Input and alignment from key stakeholders (e.g., IT, Finance, Operations, and any other departments that may be impacted).
In essence, we need to create a detailed picture of the current "as-is" state, highlighting the pain points or inefficiencies the tool is intended to address, and contrast it with the desired "to-be" state, demonstrating how this tool will solve those challenges and enhance the PMO's effectiveness. This will help address any concerns the company director might have!
...
1 reply by Mike Frenette
Nov 18, 2024 5:39 PM
Mike Frenette
...
Closer!
Saving Changes...
Mike FrenetteManager, IT PMO| Halifax Water (retired)Halifax, Nova Scotia, Canada
Nov 18, 2024 2:11 PM
Replying to Keith Novak
...
Ask for the formal written authorization/directive. Just because someone is a senior manager or works for an aggressive director doesn't mean they have unlimited authority. Finance, IT Security, and other branches of the company may require input on any non-standard software purchases and usage. Make sure you understand the rules of your own organization and that the request complies with those rules.
Yes..... Architecture too! Saving Changes...
Mike FrenetteManager, IT PMO| Halifax Water (retired)Halifax, Nova Scotia, Canada
Nov 18, 2024 5:31 PM
Replying to Rami Kaibni
...
Mike, I agree with the points raised by Kiron and Keith. However, before we move forward, I would first recommend gathering thorough details to assess the tool’s suitability for the PMO’s needs. Specifically, we would need to build a mini business case, that includes the following key areas:
1) Budget: A clear understanding of the total cost, including licensing, implementation, and ongoing support costs.
2) Technical Details: How the tool will integrate with our existing systems and infrastructure, and any technical requirements or constraints.
3) Vendor Information: A thorough assessment of the vendor’s reputation, support services, and implementation track record.
4) Stakeholder Buy-In: Input and alignment from key stakeholders (e.g., IT, Finance, Operations, and any other departments that may be impacted).
In essence, we need to create a detailed picture of the current "as-is" state, highlighting the pain points or inefficiencies the tool is intended to address, and contrast it with the desired "to-be" state, demonstrating how this tool will solve those challenges and enhance the PMO's effectiveness. This will help address any concerns the company director might have!
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Nov 18, 2024 5:39 PM
Replying to Mike Frenette
...
Closer!
Closer to what? :-)
...
1 reply by Mike Frenette
Nov 19, 2024 9:59 PM
Mike Frenette
...
To what I was going to answer. 😉
Saving Changes...
George FreemanThought Leader | Author | Architect| Florida, United States
Mike,
Although I agree with Keith and Kiron, if there is no formal or enforceable “software procurement policy,” or if this department head knows the corporate political ways around the policy, then there are times when you need to take a lesson from the proverbial old west.
Hence, when a procurement policy can’t hold its ground, it’s often best to immediately “jump into the fray” and do a quick evaluation using your best “technical – shoot it down” architect, who can get a demonstration of the product with all parties involved and in real-time ask thirty or so relevant business and technical questions that will put your user and their proposed vendor into a tailspin.
After they recover from the impact, the business users typically fall into alignment as they finally and truly understand your IT or project organization’s value. After which, you can execute appropriate due diligence without undue pressures, and who knows, everything may happen in the time frame the user desired, possibly under a different vendor or no vendor, but at least the opportunity to do what is best for the business can occur.
George
...
1 reply by Mike Frenette
Nov 21, 2024 1:10 PM
Mike Frenette
...
Interesting answer, George. I suppose there are many organizations where such a knee-jerk request would not be caught until it reached the Procurement Department. In our organization, we hope to funnel all software requests through a process we call RGI (Really Good Idea). Some RGIs are truly good ideas, others are "shoot from the hip" requests that require due diligence. In my answer below, I describe this as making sure there is a need, doing a business case, fitting the project in with all the others in the queue, defining requirements properly, ensuring there is an architectural fit, looking to see what is available, choosing the best product that meets the established budget, then planning for implementation. Of course there are many detailed steps along the way in this process that come into play to ensure a successful choice and a successful implementaiton, not the least of which is solid project and change management.
If we don't follow these processes, we risk creating expensive "shelfware" that meets few requirements and in the end is discarded. I have seen this so many times in my career that it I keep a close eye out for it now.
So... I am not sure if I need a revolver or not. Last time I tried to spin one around like the do in the wild west movies, I shot myself in the foot. ;)
(BTW - I like the tailspin approach to vetting a product. I would also throw a few other experts into the fray to make sure all the right questions are in the hopper.)
Saving Changes...
Mike FrenetteManager, IT PMO| Halifax Water (retired)Halifax, Nova Scotia, Canada
Nov 18, 2024 5:42 PM
Replying to Rami Kaibni
...
Closer to what? :-)
To what I was going to answer. 😉 Saving Changes...
Mike FrenetteManager, IT PMO| Halifax Water (retired)Halifax, Nova Scotia, Canada
I called this the silver bullet scenario for a reason. This is the bullet that solves all problems and we all know it does not exist.
I can't tell you how many times I've had people who say they must have a tool.
You fall back on what makes sense. In my opinion, which is in this case to be sure that there is a need.
Once you've done that, have your business analysts prepare a business case. If there is a case for getting a tool of this nature, you find out who is going to sponsor the project, who is going to own the project and given approval from your executive team, you put it in the list of projects that to be done.
You ask the business to prioritize this project with all the other projects that you are already doing and that are slated to be done.
When the time is right you start the project, and one of the first things you do is have a business analyst elicit the requirements that need to be met. Then you do a market scan to find the available tools that will meet as many high priority requirements as possible.
Of course you include the requester's silver bullet tool as one of the tools that will be compared against the requirements.
Then you choose the tool that meets most of the requirements and you prepare to configure and install.
This is a very high level view of one way to address this issue. It is a assuming a predictive project. If Agile, it would be done slightly differently.
My colleagues in this thread have raised many very good points that should also be taken into consideration. Saving Changes...
Community Champion
