November 5, 2020, 8:30 a.m. to 6 p.m. EDT | November 6, 2020 – February 7, 2021, On-Demand | Online Conference
Please login or join to subscribe to this thread
Before picking any tool or making any changes, I'd suggest meeting with your coworkers to elicit their needs and combine those with the objectives you have for such a platform.
Dorota - I faced this exact situation at my last two work places (I too was tasked with setting up the PMO from scratch, and in the second engagement I was providing advisory to the CIO).
My lesson learned was that teams, particularly in fast-moving / agile environments, pick the tools that works for them. Trying to change that or mandate ONE tool might be "one bridge too far" particularly for a new PMO.
With respect, my suggestion would be to pick your battles and start with creating smaller wins before tackling something as bid as this.
This is an all too common scenario, especially post-acquisition of companies. As Kiron says, you'll need to interview users to understand their needs. In the past, we've put together a matrix of applications and their features/functions. This way, we could compare each and take some of the emotion out of the discussion by focusing on capabilities. Be sure to include any IT security or compliance groups in these discussions. Also, if you're a global company, take international apps into consideration. For example, WhatsApp is used heavily in the EU, but didn't pass our data protection audit in the US.
Once you've narrowed down all the tools to one or two recommendations, bring in the senior level folks to help finalize the decision and help with communication. Though I can talk about why this specific application is chosen and give all the details, the CIO has more "street cred" than I do!
Common communication and PM tools are preferable. If you think back to the PMP exam, the number of communication channels is N * (N-1) / 2. It grows pretty quickly as you add people. Having different kinds of software needed to communicate across all the required channels will drive software costs as well as complexity for people needed to use many tools for the same information.
I don't know how much control you personally have across the organization to drive standardization. Large organizations may establish a set of best practices to mostly standardize on common software for most general tasks, and limited use of non-standard software where needed.
What is best is very subjective and include factors like your organization size and the needed functionality. A typical selection approach would be defining key attributes or qualities in the application, and rating the software across them to find those with the higher scores.
1. Do I proceed with one tool for all? May be not. You can choose a tool with a specific purpose for all, but not one general tool for all purposes. We know that to do project schedule planning, MS Project will be a good candidate; to store project documents, Sharepoint will be the best recommendation... there is no "one size fits all". So with each specific purpose, choose one tool.
2. How do I decide which tool is the best? As Kiron and Jason mentioned, you should interview your coworkers to understand their needs and their recommendations. Use Group Decision Making techniques like Brainstorming, Dephil, Voting... to choose the best one for each purpose.
3. How do I convince others to give up their preferred tools and use only one across the corporation: By engaging them in tools selecting process.
4. Where do I start and how do I make it work: Identify your purposes, specify a list candidates for each purposes, select a suitable tool for each purpose, create a plan to migrate to the selected tools step-by-step, project-by-project; you may need to train your users before moving to the new environment.
Definitely take a careful look at just why this is even a priority and what problem would be solved by having a single collaboration tool. Tackling this particular issue right at the start might not send the right message about the priorities of the new PMO.
Just to put an example which perhaps helps you, I was in charge to lead the transformation to agile in my actual work place. One of the pillars of agile is "to integrate" so I faced the same situation. Our first approach was to take a BYOND (Bring your own device) strategy but it was not possible because legal topics. Now, we are in the close to close the initiative to put in place what you stated. First of all: it is not a PMO initiative. It is a business initiative. If you do not make it visible you will fail because the characteristics of the work to be done at all levels (for example, you have to convince to the CEO that she/he will not use the favourite device any more for working (perhaps...)). On the other side, it is critical to understand the initiative in terms of architecture and in terms of the final objective. In our case, was to have the right information in the right hands in the right time to take any type of decisions and to able the process flows at all levels.
The key is: which is the business problem I am going to solve with the initiative?
Here my answers:
1-Yes. It is about to integrate and to share critical data to be transformed into information. Be carefull on your definition of "tool".
2-The tool that best fits to achieve the objective taking into account the current situation and the desiere future situation.
3-You have "to sell" the initiative. No pain, no gain. So, work on discover the pain in terms of not to have the solution in place and make it visible.
4-the first step is to understand that you will create something in order to solve a business problem. Understand the problem and mainly identify the right people that can be help you. Perhaps the following help you:
Please login or join to reply