The document discusses the process of selecting project management tools for a PMO. It covers identifying requirements, validating requirements through a proof-of-concept and pilot, and developing a business case. Key steps include understanding current pain points, prioritizing requirements, testing requirements against a basic tool, gathering feedback, and using the results to justify moving forward. The goal is to select tools that meet business needs and have support from stakeholders and executives.

1. 1

2. 2

3. -Tools can be independent or collectively-based in a single project portfolio
management (PPM) package
-Can the audience think of any other PMO tools? Is this it?
-Within the context of this presentation, we’re also going to classify the enablers of
the tools as “tools”
-Tools can be independent or collectively-based in a single project portfolio
management (PPM) package
-Can the audience think of any other PMO tools? Is this it?
-Within the context of this presentation, we’re also going to classify the enablers of
the tools as “tools”
3

4. -Processes transcend everything and the tools must adhere to the processes instead
of the processes getting moulded to fit the tools; based on the needs, is a sedan
needed or an SUV, or a luxury vs. household brand?
-Processes transcend everything and the tools must adhere to the processes instead
of the processes getting moulded to fit the tools; based on the needs, is a sedan
needed or an SUV, or a luxury vs. household brand?
4

5. -It is the data that powers the tools
-Without data, the PMO tools are like shiny cars that can only make the garage look
great but can’t take you from Point A to Point B, which is the real purpose of a car
-It is the data that powers the tools
-Without data, the PMO tools are like shiny cars that can only make the garage look
great but can’t take you from Point A to Point B, which is the real purpose of a car
5

6. -If people don’t have knowledge of the PMO tools, or don’t know what to do with
their outputs, then the tools are meaningless - much like driving a car around all over
the place but not really getting to the destination of choice
-In addition to the tools, the people must be equipped with the relevant
knowledge/experience to effectively use them and reap their benefits
-If people don’t have knowledge of the PMO tools, or don’t know what to do with
their outputs, then the tools are meaningless - much like driving a car around all over
the place but not really getting to the destination of choice
-In addition to the tools, the people must be equipped with the relevant
knowledge/experience to effectively use them and reap their benefits
6

7. -This summarizes the relationship of PMO tool with its enablers-This summarizes the relationship of PMO tool with its enablers
7

8. 8

9. -PMO tools exist for one singular purpose; they help everyone involved in the PMO
get the job done
-Assist with labour-intensive tasks
-Automate tasks where possible
-Visualize
-But what does this all mean? What does “getting the job done” mean?
-PMO tools exist for one singular purpose; they help everyone involved in the PMO
get the job done
-Assist with labour-intensive tasks
-Automate tasks where possible
-Visualize
-But what does this all mean? What does “getting the job done” mean?
9

10. -PMO tools provide the knowledge of the current: How much have we spent? What
resources are working on what?
-PMO tools enable forecasting: How much will we spend after 3 months? Will we
meet our timelines?
-PMO tools allow reporting of information relevantly and accurately
-With all this in place, they empower decision-making
-PMO tools provide the knowledge of the current: How much have we spent? What
resources are working on what?
-PMO tools enable forecasting: How much will we spend after 3 months? Will we
meet our timelines?
-PMO tools allow reporting of information relevantly and accurately
-With all this in place, they empower decision-making
10

11. -When the right PMO tools don’t exist, or its enablers are non-functional:
-Milestones can be missed
-Costs can exceed budgets
-Resources can be over-staffed, which can lead to productivity loss and morale
reduction
-Focus could shift from management to administration
-Improper prioritization can occur
-Projects could fail
-When the right PMO tools don’t exist, or its enablers are non-functional:
-Milestones can be missed
-Costs can exceed budgets
-Resources can be over-staffed, which can lead to productivity loss and morale
reduction
-Focus could shift from management to administration
-Improper prioritization can occur
-Projects could fail
11

12. 12

13. -There are 2 possibilities here-There are 2 possibilities here
13

14. -The path chosen of how a tool made its way to the organization plays a significant
role in its effectiveness and utility
-Choice Paradigm: Secondary research only
-Best tool  Complex
-Cheapest tool  Lacks key features, limited customization, slow
-Situations
-Enterprise-wide tool being forced within subsidiary  Not in sync
with organizational processes
-Adopted via M&A  Lack of interoperability
-Good tool then but not now  Tool cannot cope with the
organizational changes
-The path chosen of how a tool made its way to the organization plays a significant
role in its effectiveness and utility
-Choice Paradigm: Secondary research only
-Best tool  Complex
-Cheapest tool  Lacks key features, limited customization, slow
-Situations
-Enterprise-wide tool being forced within subsidiary  Not in sync
with organizational processes
-Adopted via M&A  Lack of interoperability
-Good tool then but not now  Tool cannot cope with the
organizational changes
14

15. 15

16. 16

17. 17

18. 18

19. -Know what you need
-What this means
-Be business-capability oriented
-Be product agnostic (e.g. Don’t think about “I want this specific
product or this specific brand of product”)
-Be aware of your pain-points
-Be specific
-Be focused (e.g. On one specific area of a PMO instead of the whole
thing, e.g. Resource management, budget management, etc.)
-Know what you need
-What this means
-Be business-capability oriented
-Be product agnostic (e.g. Don’t think about “I want this specific
product or this specific brand of product”)
-Be aware of your pain-points
-Be specific
-Be focused (e.g. On one specific area of a PMO instead of the whole
thing, e.g. Resource management, budget management, etc.)
19

20. -Before we proceed, let’s take a step back and talk a bit about what “business-
capability oriented” means
-Business capability is the ability to
-Perform a business task OR
-Obtain specific inform
-Business capability is NOT a solution or a requirement
-Before we proceed, let’s take a step back and talk a bit about what “business-
capability oriented” means
-Business capability is the ability to
-Perform a business task OR
-Obtain specific inform
-Business capability is NOT a solution or a requirement
20

21. -Know what success looks like
-What this means
-If you don’t know what success looks like, you won’t realize it once
you get there
-You will need to identify qualitative and quantitative parameters that
serve as success indicators
-You will have to time-box these parameters
-Be objective and nimble, so that if things aren’t going as planned, you
can do the root cause analysis to course-correct yourself
-Know what success looks like
-What this means
-If you don’t know what success looks like, you won’t realize it once
you get there
-You will need to identify qualitative and quantitative parameters that
serve as success indicators
-You will have to time-box these parameters
-Be objective and nimble, so that if things aren’t going as planned, you
can do the root cause analysis to course-correct yourself
21

22. -Know who is behind you
-What this means
-You need to have executive support/sponsorship
-This assists you with getting roadblocks out of your way
-Higher adoption
-Initiative is deemed more important
-Know who is behind you
-What this means
-You need to have executive support/sponsorship
-This assists you with getting roadblocks out of your way
-Higher adoption
-Initiative is deemed more important
22

23. -These three (3) elements are the pre-requisites before you get started on your
journey to get the right tools for your PMO
-They prepare your mindset, enable you to be objective and ensure you’re armed
with the proper support to get through the way
-Now let’s dive deeper into the approach and look at some strategies and tactics that
we will need to consider
-These three (3) elements are the pre-requisites before you get started on your
journey to get the right tools for your PMO
-They prepare your mindset, enable you to be objective and ensure you’re armed
with the proper support to get through the way
-Now let’s dive deeper into the approach and look at some strategies and tactics that
we will need to consider
23

24. 24

25. -Again, before getting started, we should have our pre-requisites in place: 1) have
executive sponsorship, 2) hone down the PMO area(s) that require work (e.g.
Resource management, financial management), and based on 1) & 2), obtain people
resources and SMEs for support
-For each component of the approach, we will cover its intent and the actions that
are required to deliver the expected results/outputs
-Again, before getting started, we should have our pre-requisites in place: 1) have
executive sponsorship, 2) hone down the PMO area(s) that require work (e.g.
Resource management, financial management), and based on 1) & 2), obtain people
resources and SMEs for support
-For each component of the approach, we will cover its intent and the actions that
are required to deliver the expected results/outputs
25

26. -Requirements Identification:: Intent
-To understand where you want to go, you first need to understand where you
currently are
-Examine your current state and determine what your pain-points are
-Are they painful enough to go through a major change or will minor tweaks
make the difference?
-Requirements Identification:: Intent
-To understand where you want to go, you first need to understand where you
currently are
-Examine your current state and determine what your pain-points are
-Are they painful enough to go through a major change or will minor tweaks
make the difference?
26

27. -Requirements Identification:: Action
-With the key resources engaged, ensure that there is communication with
the leadership team, management team, SMEs and everyone in between
-Conduct interviews, surveys, workshops/JAD session
-Discuss historical issues, current pain-points, current positive items and
future capabilities
-Review information and put an objective lens to determine business
capabilities and requirements
-Determine protocol to prioritize (number scheme, must-have vs. nice-to-
have)
-Solicit consensus from the key stakeholders on the requirements
prioritization
-Identify key metrics that can be used to measure success from requirements
meeting, operationalization, and adoption perspective
-Requirements Identification:: Action
-With the key resources engaged, ensure that there is communication with
the leadership team, management team, SMEs and everyone in between
-Conduct interviews, surveys, workshops/JAD session
-Discuss historical issues, current pain-points, current positive items and
future capabilities
-Review information and put an objective lens to determine business
capabilities and requirements
-Determine protocol to prioritize (number scheme, must-have vs. nice-to-
have)
-Solicit consensus from the key stakeholders on the requirements
prioritization
-Identify key metrics that can be used to measure success from requirements
meeting, operationalization, and adoption perspective
27

28. -Requirements Identification:: Result
-These items serve as pre-requisites for the next phase: Requirements
Validation
-Requirements Identification:: Result
-These items serve as pre-requisites for the next phase: Requirements
Validation
28

29. -Requirements are a “need” or “want”
-Extend the business-capabilities’ “what” – don’t delve into the “how”
-Be specific and provide information (avoid ambiguity)
-Requirements are a “need” or “want”
-Extend the business-capabilities’ “what” – don’t delve into the “how”
-Be specific and provide information (avoid ambiguity)
29

30. -Requirements Validation:: Intent
-POC
-Build, buy, or try (this decision is based on budget, time, resource and
skill availability, and the nature of buy/try tools that exist in the
market)
-The purpose is to have something basic that meets the requirements
identified in the earlier phase
-Have change management aspects in place before initiating the pilot
(support center, basic training, job aid, communication, incentives,
view of future benefits)
-Pilot
-Leverage the team in place and ask them to conduct a pilot on the
POC
-The important thing to consider is here is not to focus on how well
the tool did, but how the requirements fared the “real-life” test, and
how did the enablers of the tool (people, process and data) hold up
-Requirements Validation:: Intent
-POC
-Build, buy, or try (this decision is based on budget, time, resource and
skill availability, and the nature of buy/try tools that exist in the
market)
-The purpose is to have something basic that meets the requirements
identified in the earlier phase
-Have change management aspects in place before initiating the pilot
(support center, basic training, job aid, communication, incentives,
view of future benefits)
-Pilot
-Leverage the team in place and ask them to conduct a pilot on the
POC
-The important thing to consider is here is not to focus on how well
the tool did, but how the requirements fared the “real-life” test, and
how did the enablers of the tool (people, process and data) hold up
30

31. -Requirements Validation:: Action
-Of course, the POC & pilot management will be one of the primary activities
here
-Once the pilot is done, a review must be done to understand how well the
requirements were met or not met
-Obtain summary from pilot users and update metrics accordingly
-Obtain their feedback and recommendations
-Were these truly the requirements that the stakeholders wanted? Should
there be any modifications? Update the requirements accordingly
-Use the information collected (pilot parameters such as timelines and costs,
success metrics, benefits, finalized requirements) along with executive
sponsorship support on the pilot to build the business case required to move
to the next phase
-Requirements Validation:: Action
-Of course, the POC & pilot management will be one of the primary activities
here
-Once the pilot is done, a review must be done to understand how well the
requirements were met or not met
-Obtain summary from pilot users and update metrics accordingly
-Obtain their feedback and recommendations
-Were these truly the requirements that the stakeholders wanted? Should
there be any modifications? Update the requirements accordingly
-Use the information collected (pilot parameters such as timelines and costs,
success metrics, benefits, finalized requirements) along with executive
sponsorship support on the pilot to build the business case required to move
to the next phase
31

32. -Requirements Validation:: Result
-A strong business case is required to kick-start key initiatives
-Proven, practical tie-ins of requirements to organizational goals and
objectives make business cases extremely relevant
-Hence, the upfront work done here comes quite handy when you reach to
this point: it becomes a very convincing story to tell
-Requirements Validation:: Result
-A strong business case is required to kick-start key initiatives
-Proven, practical tie-ins of requirements to organizational goals and
objectives make business cases extremely relevant
-Hence, the upfront work done here comes quite handy when you reach to
this point: it becomes a very convincing story to tell
32

33. -Guiding forces
-Determine the PMO capability that needs to be considered (schedule, resource,
time, budget, etc.)
-Invest some time in research, do basic option comparisons in terms of what “seems”
sufficient and start trying it out
-Understand what is the budget and time at hand to do the POC and the pilot
-Assess the easiness of procuring/building/learning the tool
-Check if there are any other special requirements (e.g. on the cloud, mobile-
optimized)
-Make decision on tool (build or try – free or limited trial)
-Again, the goal here is to validate or invalidate requirements, not assess the
feasibility of the tool
-Suggestions (not recommendations) include, Asana, AtTask (now Workfront),
Mavenlink, Basecamp, Microsoft Excel, Microsoft Project, Zoho, Wrike
-Caution: do not consider mature and complex PPM tools
-Guiding forces
-Determine the PMO capability that needs to be considered (schedule, resource,
time, budget, etc.)
-Invest some time in research, do basic option comparisons in terms of what “seems”
sufficient and start trying it out
-Understand what is the budget and time at hand to do the POC and the pilot
-Assess the easiness of procuring/building/learning the tool
-Check if there are any other special requirements (e.g. on the cloud, mobile-
optimized)
-Make decision on tool (build or try – free or limited trial)
-Again, the goal here is to validate or invalidate requirements, not assess the
feasibility of the tool
-Suggestions (not recommendations) include, Asana, AtTask (now Workfront),
Mavenlink, Basecamp, Microsoft Excel, Microsoft Project, Zoho, Wrike
-Caution: do not consider mature and complex PPM tools
33

34. -Do the relevant processes need any optimization?
-Does the data require population, refinement or normalization?
-Do the people involved need to be trained/coached on project management
principles or anything organization specific (e.g. Processes) before the tools can be
introduced?
-Before the focus is shifted to identifying and getting the right tool on-board, these
course-corrections, especially around the processes, must be executed (data and
people issues can also potentially be addressed during tool implementation but
preference is to start at the earliest)
-Do the relevant processes need any optimization?
-Does the data require population, refinement or normalization?
-Do the people involved need to be trained/coached on project management
principles or anything organization specific (e.g. Processes) before the tools can be
introduced?
-Before the focus is shifted to identifying and getting the right tool on-board, these
course-corrections, especially around the processes, must be executed (data and
people issues can also potentially be addressed during tool implementation but
preference is to start at the earliest)
34

35. -Tool Identification:: Intent
-Obtain continued executive support
-Understand scope (how many requirements, areas of impact), budget and
timeline
-Use these elements to create guiding principles for decision making
-Create decision making team and governance
-Understand level and availability of skills in-house
-Tool Identification:: Intent
-Obtain continued executive support
-Understand scope (how many requirements, areas of impact), budget and
timeline
-Use these elements to create guiding principles for decision making
-Create decision making team and governance
-Understand level and availability of skills in-house
35

36. -Tool Identification:: Action
-Use the guiding principles and decision making team to determine
-Should the tool be procured or built?
-If procured, should the same tool be used that was used in the
POC?
-If built, can our own resources build it or do we need external
help?
-Shall we use any of our preferred vendors or the tool’s
professional services team?
-Should the roll-out support be managed internally?
-Do we have the right skills and/or capacity for it?
-Do we external on this one as well?
-Build decision tree and selection criteria/scorecard for tool
-Determine timeline for this process
-Determine tool (short-list options, request for demos, understand fit
with business requirements & technical complexity, cost,
sustainability)
-Proceed with vendor engagement process where required (create,
issue & assess RFIs/RFPs, short-list, present)
-Vendor selections
-Tool Identification:: Action
-Use the guiding principles and decision making team to determine
-Should the tool be procured or built?
-If procured, should the same tool be used that was used in the
POC?
-If built, can our own resources build it or do we need external
help?
-Shall we use any of our preferred vendors or the tool’s
professional services team?
-Should the roll-out support be managed internally?
-Do we have the right skills and/or capacity for it?
-Do we external on this one as well?
-Build decision tree and selection criteria/scorecard for tool
-Determine timeline for this process
-Determine tool (short-list options, request for demos, understand fit
with business requirements & technical complexity, cost,
sustainability)
-Proceed with vendor engagement process where required (create,
issue & assess RFIs/RFPs, short-list, present)
-Vendor selections
36

37. -Tool Identification:: Result
-All pieces should be in place now
-Tools and vendors (if applicable) identified
-Its now time for implementation
-Tool Identification:: Result
-All pieces should be in place now
-Tools and vendors (if applicable) identified
-Its now time for implementation
37

38. -Tool Implementation:: Intent
-This is the final, launch stage, and a huge one to say the least, no matter how
many people or departments the roll-out is for
-Need to on-board all relevant parties and start the detailed planning
-Tool Implementation:: Intent
-This is the final, launch stage, and a huge one to say the least, no matter how
many people or departments the roll-out is for
-Need to on-board all relevant parties and start the detailed planning
38

39. -Tool Implementation:: Action
-The entire implementation has to be “projectized”
-POC & pilot
-We will need to do a POC and pilot again on the tool selected
-Previously, the focus was on validating the requirements and
how the enablers held up
-Now the focus is on ensuring that the tool is a right-fit and
how it needs to be customized with processes in place
-Project Management Lifecycle (PMLC), Software Development
Lifecycle (SDLC) & governance
-Like any software implementation project, establish the
governance based on PMLC and SDLC pertaining to your
organization
-Establish timelines (including a program schedule if required),
resource accountabilities, reporting mechanisms to
stakeholders
-Determine need for additional procurement of infrastructure
-Plan for iterative roll-outs
-Ensure change management is being planned for in parallel – this is
key for adoption and reinforcement
-Communication plan
-Support center creation
-Adoption metrics and project success determination (how
much is the tool being used, is it being used for what it was put
in place for, is it being used correctly, are the expected results
evident)
-Training/knowledge transfer plan
-Job aids/cheat sheets
-Tool Implementation:: Action
-The entire implementation has to be “projectized”
-POC & pilot
-We will need to do a POC and pilot again on the tool selected
-Previously, the focus was on validating the requirements and
how the enablers held up
-Now the focus is on ensuring that the tool is a right-fit and
how it needs to be customized with processes in place
-Project Management Lifecycle (PMLC), Software Development
Lifecycle (SDLC) & governance
-Like any software implementation project, establish the
governance based on PMLC and SDLC pertaining to your
organization
-Establish timelines (including a program schedule if required),
resource accountabilities, reporting mechanisms to
stakeholders
-Determine need for additional procurement of infrastructure
-Plan for iterative roll-outs
-Ensure change management is being planned for in parallel – this is
key for adoption and reinforcement
-Communication plan
-Support center creation
-Adoption metrics and project success determination (how
much is the tool being used, is it being used for what it was put
in place for, is it being used correctly, are the expected results
evident)
-Training/knowledge transfer plan
-Job aids/cheat sheets
39

40. -Tool Implementation:: Result
-With the tool implemented and people, process and data in place, early focus
must be kept on reinforcement
-If vendor(s) were identified for build/roll-out support, work on knowledge
transfer and self-sufficiency of the organization
-Expect some growth pains and some non-compliance but ensure that
corrective actions are being executed
-Reward and recognize good behaviour and celebrate the little wins
-Empower the owners of the tool and ensure metrics are being measured for
continuous improvement
-So there you have it: the requirements-based approach to identify and
implement the right tool for your PMO
-Tool Implementation:: Result
-With the tool implemented and people, process and data in place, early focus
must be kept on reinforcement
-If vendor(s) were identified for build/roll-out support, work on knowledge
transfer and self-sufficiency of the organization
-Expect some growth pains and some non-compliance but ensure that
corrective actions are being executed
-Reward and recognize good behaviour and celebrate the little wins
-Empower the owners of the tool and ensure metrics are being measured for
continuous improvement
-So there you have it: the requirements-based approach to identify and
implement the right tool for your PMO
40

41. 41

42. -Drivers & Pain-points
-Nothing exists (or very limited availability)
-Need to quickly understand the landscape and maturity of the organization
(culture, requirements, status of enablers, painpoints)
-Focus on tools accordingly
-Don’t need to start from scratch, there are a lot of options to get on your feet
quickly
-PMO leads often bring their past experiences to set things up quickly
-“PMO-in-a-box” type of solutions where MS Office tools/templates
are all available that can be easily customized based on the enablers at
the organization
-It is however the requirements tied to the business capabilities, which
are linked to the organizational objectives that lead to the proper roll-
out of the tools
-Drivers & Pain-points
-Nothing exists (or very limited availability)
-Need to quickly understand the landscape and maturity of the organization
(culture, requirements, status of enablers, painpoints)
-Focus on tools accordingly
-Don’t need to start from scratch, there are a lot of options to get on your feet
quickly
-PMO leads often bring their past experiences to set things up quickly
-“PMO-in-a-box” type of solutions where MS Office tools/templates
are all available that can be easily customized based on the enablers at
the organization
-It is however the requirements tied to the business capabilities, which
are linked to the organizational objectives that lead to the proper roll-
out of the tools
42

43. -Drivers & Pain-points
-Some tools could be working fine but there could be challenges in certain
areas
-To get a perspective, understand how the tools were brought on and assess if
that could lead to some root causes
-Determine if any of the enablers are not working
-Some minor changes here could lead to high value improvements
-But if this doesn’t work, and indeed the problem is with the tool, then this
requirements-based approach needs to be considered
-Drivers & Pain-points
-Some tools could be working fine but there could be challenges in certain
areas
-To get a perspective, understand how the tools were brought on and assess if
that could lead to some root causes
-Determine if any of the enablers are not working
-Some minor changes here could lead to high value improvements
-But if this doesn’t work, and indeed the problem is with the tool, then this
requirements-based approach needs to be considered
43

44. -Drivers & Pain-points
-With mature PMOs, issues are usually around the enablers
-Have the processes become too complex?
-Are the people not familiar with the tools? Are certain areas of the
organization more mature than others? Are the people new to the
organization not knowledgeable about the tools?
-Is the submission or usage of data not standardized?
-These are some of the pain-points that you can see with mature PMOs and
can be fixed when focusing on these areas
-There are also situations where mature PMOs have portfolio project
management (PPM) tools but they aren’t being used to their fullest extent
-Were these PPM tools a wrong choice for the organization?
-The requirements-based approach could help determine this (and
we’ll talk more about it in our case study)
-Drivers & Pain-points
-With mature PMOs, issues are usually around the enablers
-Have the processes become too complex?
-Are the people not familiar with the tools? Are certain areas of the
organization more mature than others? Are the people new to the
organization not knowledgeable about the tools?
-Is the submission or usage of data not standardized?
-These are some of the pain-points that you can see with mature PMOs and
can be fixed when focusing on these areas
-There are also situations where mature PMOs have portfolio project
management (PPM) tools but they aren’t being used to their fullest extent
-Were these PPM tools a wrong choice for the organization?
-The requirements-based approach could help determine this (and
we’ll talk more about it in our case study)
44

45. 45

46. -You need to have the grand, bold vision in sight, with all pieces in place, but you
should take one step at a time
-Focus on one PMO capability before going to the other
-Roll-out to certain areas of the organization before moving to the rest
-This may seem like a slower approach, but proven success and momentum in
one area can lead to faster overall adoption
-You need to have the grand, bold vision in sight, with all pieces in place, but you
should take one step at a time
-Focus on one PMO capability before going to the other
-Roll-out to certain areas of the organization before moving to the rest
-This may seem like a slower approach, but proven success and momentum in
one area can lead to faster overall adoption
46

47. -This is instrumental in making your initiative in success
-With engaged sponsors who are interested in the success of the initiative, they will
not only ensure that they are able to remove the roadblocks from your way, they will
ensure adoption is facilitated within target areas, and also champion the cause to the
rest of the organization
-You need to ensure that the sponsors remain engaged by being transparent in status,
challenges and wins
-This is instrumental in making your initiative in success
-With engaged sponsors who are interested in the success of the initiative, they will
not only ensure that they are able to remove the roadblocks from your way, they will
ensure adoption is facilitated within target areas, and also champion the cause to the
rest of the organization
-You need to ensure that the sponsors remain engaged by being transparent in status,
challenges and wins
47

48. -Complete adoption can take some time, so ensure that the expectations are set
accordingly
-There could be opportunities for some quick wins once things are in motion, but
they will only show that you’re heading down the right path, not that you’ve reached
your destination
-Complete adoption can take some time, so ensure that the expectations are set
accordingly
-There could be opportunities for some quick wins once things are in motion, but
they will only show that you’re heading down the right path, not that you’ve reached
your destination
48

49. -In the journey of pilot to adoption, metrics are your best friends
-They can indicate how the requirements have been validation, how effective the
tools have been, and how supportive the enablers have been
-Have some meaningful drill-downs here (e.g. By PMO area or by organizational
business units) to understand how adoption is relative across the board and which
areas need some help with reinforcements
-In the journey of pilot to adoption, metrics are your best friends
-They can indicate how the requirements have been validation, how effective the
tools have been, and how supportive the enablers have been
-Have some meaningful drill-downs here (e.g. By PMO area or by organizational
business units) to understand how adoption is relative across the board and which
areas need some help with reinforcements
49

50. -Sometimes you become really attached to the interim solutions (often seen during
pilots) because they are really working out for you
-You have to let them go
-Focus on the requirements that they’ve helped validate and use that to get to your
final solutions
-Did you hit gold with the interim solution? Should that really be your final solution?
Let the requirements guide you to this answer
-Sometimes you become really attached to the interim solutions (often seen during
pilots) because they are really working out for you
-You have to let them go
-Focus on the requirements that they’ve helped validate and use that to get to your
final solutions
-Did you hit gold with the interim solution? Should that really be your final solution?
Let the requirements guide you to this answer
50

51. 51

52. 52

53. 53

54. 54

55. 55

56. 56

57. 57

58. 58

59. 59