Leadership & Management in Projects--Two Sides of the Same ...
Transcript of Leadership & Management in Projects--Two Sides of the Same ...
Session ID:
Prepared by:
Remember to complete your evaluation for this session within the app!
Quest2019-103630
Leadership &
Management in
Projects--Two Sides of
the Same Coin
10-April-2019
David Fuston
Engagement Manager
Grant Thornton
Leadership and Management – Two Sides of Same Coin
Session Objectives
Objective #1: Discuss the root causes of obstacles/problems encountered in
multiple implementations, share common themes across all/multiple teams, how
each issue was addressed/resolved, and what the lessons learned are about
what can be done to prevent/minimize impact on future projects.Objective #2: Discuss the consulting company’s s assessment of executive or
business sponsor’s readiness to start the project, what we actually found during
implementation, and accuracy of the assessment from a business
sponsor/stakeholder viewpoint
Objective #3: Discuss the Program Management Office and Steering
Committee governance structure, along with what worked, what did not and
where the PMO underestimated magnitude of the change necessary.
Objective #4: Discuss the definitions and measurements for project success.
Agenda
Speaker and Company
Leadership and Management
Strategic objectives and project management tools
Team structures and time management
Stakeholder participation
Basic infrastructure and software licensing
Adequate skillsets
Questions and Answers
About the presenter
David Fuston is an certified PM and Engagement Manager with Grant
Thornton, Enterprise Applications Strategy and Integration Group, based in
Overland Park, KS, concentrating on strategic assessments, global process
engineering, governance controls, applications design and development, and
portfolio management.
His expertise is in program oversight of Oracle Fusion Applications
R10/11/12/13, EBS 11i/R12, and Hyperion HFM/Planning 7/9. He has been a
technical author and speaker at Oracle OpenWorld, ODTUG, IOUG, OAUG,
HEUG, and multiple Collaborate user group conferences.
About Grant Thornton
6
Office locations
Reach
Our services
59 offices spread across 30 states and Washington D.C.
Serve 36% of companies on the
2017 Fortune 500 list and 25% of
companies on the Russell 2000 list
• Assurance • Tax • Advisory
PeopleMore than 8,500 professionals in the U.S.
Partners594 partners serving more than 8,000 clients in the nation
RevenueGT U.S. net revenue equals $1.74 billion
stats are as of 07/31/2017
Distinguishing between Leadership and
Management
• Leadership involves managing and management involves leading. Project
managers do both.
• Leadership is usually described as an influence process by an individual toward
a group in the pursuit of achieving a set of goals or objectives. It also involves
setting those goals and objectives for the organization to pursue.
• Management is the process of coordinating, influencing, and organizing the
activities in an organization in the achievement of the business goals.
• Leaders set objectives and direction while managers conduct the efforts
necessary to achieve them.
• Where leadership is described as affecting change, management is described
as creating order.
Koontz and O’Donnell List of Management
Functions
•Planning – L & M
•Organizing -- M
•Staffing -- L & M
•Directing -- L
•Controlling -- L & M
Two myths of Project Management &
Management Realities
• Myth #1 Project manager's competence makes no contribution to project success. Aka, the right tools and techniques will make the project successful.
• Myth #2 Project Manager can learn to apply those tools and techniques to any type of project, regardless of technology, discipline, or domain. So, the tools manage the project, not the person.
• Reality: Both myths are in direct conflict with general management literature, where a manager's competence makes a direct contribution to an organization success, and different competency profiles are required in different circumstances, including project management.
• Reality: Competence to manage can be defined as knowledge, skills, leadership style, and personal characteristics to achieve the desired result. Different competency profiles are required to manage types of different projects, and one project manager may be more competent than another, depending on the project.
13
STRATEGIC OBJECTIVES
• Executive consensus re: business justification
– GT Project Readiness Assessment**
• Internal Appropriation Request
• Project Charter Document
– Absolute, nice to have, wish list requirements
– Measurements of Success**
– Progress Tracking tools**
• To Be Process Definitions
– Data Needs Analysis
– Reporting Needs Analysis**
** lessons learned apply here
Common Oracle PROJECT CHARTER Scenario
• SITUATIONS:
– Multiple executive project sponsors/stakeholders are required since projects cross departments, functions, groups, and locations
– Project funding has a built-in assumption regarding both risk and spending tolerance
– Project sponsors all agree on top 5 objectives ("What"), but have not discussed the "How" details
– Reality is that project management tools focus on process and data flows, not tribal knowledge, information silos, nor people management
– Reality is that putting in an ERP system requires new thinking on data relationships, logical business requirements, who does what in revised process flows, and sharing information.
14
Common Oracle PROJECT CHARTER Scenarios
• Leadership LESSONS:
– Re-engineering several core business processes objective is
not necessarily consistent with controlled spending caps nor
reducing risk
– Change Management is about all three pillars together--
people, processes and technology
– Sponsor/stakeholder inconsistencies are costly in both time,
money, and rework.
15
Common Oracle ERP Reporting Scenario
• SITUATIONS:
– ERP team has belief that basic reporting will be provided by out-of-the-box standard reports, or XML or FSG reports
– ERP team believes that Cognos, OBIA, Hyperion, etc. could be installed later for more complex reporting
– Reality is that neither assumption is correct
– Reality is that putting in ERP system without planning for reporting is like building a house without considering plumbing or electrical connections
16
Common Oracle ERP Reporting Scenario
• LESSONS:
– If you do not take the time up front to gather and plan for the
reporting requirements, you may not have the information
available when you need to access it
– Planning ahead means performing a "reporting needs
analysis"
– Incorporation of reporting requirements into ERP
applications design and configuration
17
19
TEAM STRUCTURES
• Team Design
– Representative balance across the process flow on each team**
– Process flow thought patterns
– Data analysis and processing logic capabilities**
– Team player attitude versus individual contributor
– Soft people skills/communications
– Roles and responsibilities**
• Inter-team Coordination
– Progress tracking tools (time, schedule, resources, updates) **
– Shared pool resource constraints
– Data quality
– Governance and oversight reporting**
** lessons learned apply here
Team Design
• SITUATIONS:
– Process flow knowledge is limited across departments to
very few personnel
– Data usage knowledge is limited, and same data fields have
different meanings to different groups/different reports
– Team lead was picked due to current supervisor role, not
process flow knowledge nor people skills
– Team has not yet completed "AS IS" process flow diagrams
and/or lacks functional documentation when project starts
20
Team Design
• LESSONS:
– Team lead needs process thought patterns above all else to
make solution design complete and comprehensive
– Data Quality, relationships, values, usage and reporting is
every team member's responsibility
– Basic Oracle Education of modules features and functionality
for key team members is required before, not after, discovery
begins in an implementation
21
Inter-team coordination
• SITUATIONS:
– Multiple teams have belief that shared IT pool technical resources are always available when they need their services
– Program Management Office (PMO) and/or steering committee is perceived as asking too many questions, too demanding for weekly updates on schedule/scope, and requiring too much for business justification in written scope change docs
– Reality is that each team needs both functional SMEs, process BPAs, technical developers, IT support, and reportwriters from kickoff phase thru transition to PROD phase to ensure design balance, data quality, and business effectiveness
– Reality is that most team process decisions are based on who is the loudest, not what is the best process for the company
22
Inter-team coordination
• LESSONS:
– "Culture eats strategy for lunch" regarding inter-team
cooperation
– Recommend that all client team members interview and
accept the outside consultant (works both ways) before
arrival onsite
23
25
STAKEHOLDER PARTICIPATION
• Stakeholder Responsibilities
– Strategic oversight, including risks and mitigation **
– Scorecard Accountability for schedule, results, costs, and data quality
– Back filling team members on day-to-day operations to maintain schedule, costs, quality, and process improvements **
– Final decision maker for escalated topics
– Maintain organizational alignment for project benefit
– Measurement logistics and accuracy **
• Change management
– Consistency and repetition in message and content **
– Scope Change Management **
– Vision and Thought Leadership
– Support and deliver commitment for people, process, and technology changes
– Project/program repository **
** lessons learned apply here
Stakeholder responsibilities
• SITUATIONS:
– VP of HR added to project sponsors when fellow executives realized that they were missing structural/architectural design integration considerations
– HR tribal knowledge not documented in "AS IS" process diagrams, and now being processed as change orders
– HR-BEN testing scripts not tied to business requirements
– Data translations, derived data calculations, massaged data, and inserted missing data makes for a confusing data quality discussion for reporting
26
Stakeholder responsibilities
• LESSONS:
– Standardized measurements across teams/groups/locations enables progress reporting using same definitions, same testing methods, and allows accurate progress comparisons over time
– Identification of critical reports early in discovery process drives data field verifications, data scrubbing requirements, aligns configurations, and dramatically reduces risk
– Business sponsor/stakeholder recognition overcomes multiple contentious issues if he/she continues to reward appropriate behavior in public
– Stakeholders must be active and visible
27
Change managementSITUATIONS:
– Separate non-integrated repositories for functional, technical and process documentation
– MS office (Excel, Word, Access) documentation natively does not contain version control capabilities
– Each agile iteration produces some level of surprises, and sometimes new functionality
– "TO BE" process flows require considerable discipline and thought process, taking anywhere from 3-7 reviews before becoming stable, especially if re-engineering is involved
– The world is full of auditory, visual, and kinesthetic personnel, all with varying degrees of absorption of new concepts/materials in training/knowledge transfer
– Scope changes, data quality, modifications to native functionality, and resource constraints are all deadly threats to a project success
28
Change management
LESSONS:
– Change is our friend; treat change as if he/she were a friend; be the change
– Team Checkpoint gates are a necessary evil to ensure readiness for the next step
– Single project repository for all project teams (functional and technical) combined with version control and documentation standards enables maximum quality and training efficiency
– Personalizations to hide/mask/display data is a necessary evil in every project for data access control.
29
31
Control in Infrastructure and Testing
• Infrastructure
– Code and Configuration freezes ahead of each testing cycle enable repeatable and consistent testing results, and are especially useful in troubleshooting and comparisons
– Oracle environment(s) should contain enough instances to enable testing strategy & patching strategy over life of project
– Integration/interface testing generally requires special attention from IT support staff
– Security, access controls, and sensitive data will generally vary by instance during the life of the project
– Instance migration of objects, configurations, and security is an opportunity to introduce unintended consequences **
– Data loading from scratch for each instance can be burdensome unless some level of cloning or data refresh is used **
– Some functionality requires at least shared access to other modules due to technical data integrations/schemas under the covers—this is normal and generally does not affect licensing
** lessons learned apply here
Infrastructure and testing controls
• SITUATIONS:
– Clone from Prod combined with latest development code freeze and a data refresh produces inconsistent or unexpected results from previous testing
– No comparisons/verifications between instances was completed before instance was approved for use by end users
– Data conversion methods were changed between instances and now data integrity is being questioned
– Regression testing is generating fails in tests which previously had passed
– Restore from backup is not functioning as expected
32
Infrastructure and testing controls
• LESSONS:
– Internal controls and standardized methods can greatly improve instance creation and verification reliability
– Documentation created by one professional must be used by separate professional to ensure that the documentation quality is complete and accurate to produce reliable results
– Testing strategies, methods, and test scripts need documentation updates after each testing cycle in the checkpoint gate review
– Service level agreements can help set expectations among diverse groups
33
35
SKILLSETS AND TRAINING
• Skillsets
– Identification of "TO BE" roles post go-live, and mapping of current team members to these roles **
» Identification of current skillsets and skill levels using standard industry definitions, including any remedial efforts unassociated with project
– Identification of quantity and level of skill gaps **
» Master list of options to close the gaps
• Training
– Identification of certification level or knowledge mastery required for each position/role/job **
– Training class matrix with headcount, costs and training delivery options for each gap for project approval
– Schedule and travel logistics plan for all approved training
** lessons learned apply here
Skillsets and training
• SITUATIONS:
– VP of HR has identified skill gaps outside of the project as a result of a
strategic succession planning exercise
– HR has controlled budgets manually regarding training approval
requests in the past, and now faces native workflow functionality with
CFO approval, including training approval requests
– HR has created new positions with new skill requirements in new
system to overcome a backlog of pending updates not yet processed in
the legacy system
– CFO has approved new spending approval levels and other changes
for certain management positions in supervisory hierarchy
36
Skillsets and training
• LESSONS:
– "AS IS" and "TO BE" skill assessments need to be
accurately correlated to positions using industry standard
definitions
– Training quality must be an active consideration in change
management planning
– Training spending and costs should be based on magnitude
of process/people/technology changes
37
Session ID:
Remember to complete your evaluation for this session within the app!
Quest2019-103630
Cell: (816)-729-1033
Don't miss these insightful sessions
9:15–10:15 a.m.
Monday
ORC strategies for Taleo
Ken Fontenot, Grant Thornton
CC 3rd FL 303A
*Global transformation cloud deployment of HCM, ERP and
more: GP Strategies case study
Dan Mills, Grant Thornton and Sonia Ardeel, GP Strategies
CC 3rd FL 302B
10:30–11:30 a.m.
Tuesday
10:30–11:30 a.m. Maximizing Oracle Payroll in the cloud—a case study on
developing a PaaS extension for HCM CloudChirag Hingrajia, Grant Thornton
CC 3rd FL 303B
12:45–1:45 p.m. You’ve upgraded to JDE 9.1; now what?
Mohammad Shujaat, Grant Thornton
GH 2nd FL Lonestar Salon E
Textile provider with unique E1 9.2 upgrade project from
both JDE World A7.2 & E1 9.0Craig Davied, Grant Thornton
GH 3rd Fl Travis B
*Implementing Oracle Cloud Revenue Management at Valet
Living—the good, the bad, the ugly
Mike Coburn, Grant Thornton and David Boyer, Valet Living
CC 3rd FL 301B
2–3 p.m.
4:30–5:30 p.m.
Wednesday
8–9 a.m. Connecting the empire—a case study of ERP Cloud integration
automation at Caesars EntertainmentLee Huff, Grant Thornton
CC 3rd FL 302C
*Caesars Entertainment’s successful transformation to financial
reporting on Oracle Cloud ERP
Prasanna Ramakrishnan, Grant Thornton
CC 3rd FL 302C
12:45–1:45 p.m.
Leadership & management in projects—two sides of the same coin
David Fuston, Grant Thornton
CC 3rd FL 302B
12:45–1:45 p.m.
Order management/advanced pricing SIG panel discussion: Journey
to the cloudBobby Smith, Grant Thornton
CC 2nd FL 225D
2–3 p.m.
Thursday
*Tax Reporting: Impact of the US tax reform
Julien Coudrette, Grant Thornton
CC 2nd FL 217C
Enhancing business processes with Procurement Cloud document
approvalsBobby Smith Grant Thornton
CC 2nd FL 225D
8–9 a.m.
9:15–10:15 a.m.
*CPE credit offered
Helping customers plan, deploy and optimize
Oracle technology solutions
• The real story: customer stories about victories and pain points along their Oracle journeys
• Career-changing connections: guidance and support from a community of users withshared interests
• Wealth of resources: entire catalog of webinars, blogs, customer stories, community surveys, whitepapers and more
• Virtual and face-to-face events: connect and learn from peers, Oracle teams and thought leaders on global, regional and local scale
• Membership benefits: questoraclecommunity.org/membership
Visit Quest Oracle Community at booth #243