Organizations, teams and even project management software are increasingly responding to a demand for more adaptive and evolutionary processes. In a fast-changing business world that needs to respond to rapid market and technology shifts, Agile delivers. Agile project management provides numerous benefits to organizations, project teams, and products.
Learn more about:
» Set up an Agile project.
» Assign roles and responsibilities.
» Create a prioritized list of requirements.
» Define increments and timeboxes.
» Manage a Solution Development Team or Teams.
» Use Agile techniques such as Feature Driven Development.
» Present the benefits of Agile approaches to Senior Management.
digital Human resource management presentation.pdf
What are the Tools & Techniques in Agile Project Management?
1. Agile Project Management
We manage learning.
“Building an Innovative Learning Organization. A Framework to Build a Smarter
Workforce, Adapt to Change, and Drive Growth”. Download now!
8. Challenges of a Project Manager
1. Dealing with changing requirements (Scope Creep)
2. Lack of resources and/or Quality of resources
3. Unrealistic schedules
4. Issues with technologies – unproven, nascent
5. Overburdened by existing complexity – documentation, reporting,
etc.
6. Too many dependencies
7. Managing stakeholder expectations
8
10. Waterfall Model
10
1. Simple and easy to understand and use.
2. Easy to manage due to the rigidity of the model.
3. Phases are executed and completed one at a time. No overlaps.
4. Works well for non-complex projects.
11. Understanding the Waterfall Model
11
1. Freeze the end-product in all respects when project starts
2. Requires detailed estimation and planning upfront
3. Changes mid-way can cause delays
12. Challenges with the Waterfall Model
1. Managing changing requirements during the ALM/SDLC
2. Don’t get to see the end product until the end of ALM/SDLC
3. Loaded with risk and uncertainty
4. Challenges in dealing with complexity upfront
12
14. Understanding Agile Development
• Agile Development is an alternative to traditional project
management
• Focus on customer satisfaction
• Adapts well to deal with uncertainties and changing situations
• Delivers in increments following an iterative process
• Continuous attention to all aspects of delivery – Planning, Design,
Delivery, Quality...
• Empowers team to make decisions
• Follows an inspect-and-adapt approach
14
19. Projects Suited for Agile Delivery
19
The most appropriate projects for agile are ones with aggressive
deadlines, high degree of complexity, and high degree of novelty
(uniqueness) to them.
Novelty: If you are building the same things
over and over again, you have mastered the
nuances. You don’t need Agile
Urgency : Time boxes and iterations keeps the
intensity and focus going
Complexity: Anything that requires that extra
bit of functionality or variation that is unique.
23. The Paradigm Shift
23
• Plan Driven Approach: Scope remains fixed, while Resources and Schedules are
adjusted
• Change Driven Approach: Scope is adjusted while Resources and Schedules are
fixed
26. 12 Principles of Agile Development
26
1. Satisfying customer is top priority
2. Welcome changing requirements even late in development
3. Deliver working software frequently
4. Development teams and business work together
5. Most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
6. The primary measure of success is working software
7. The Team regularly reflects on work
8. Build projects around motivated people
9. Continuous attention to technical excellence and good design
10. Simplicity – the art of maximizing the amount of work not done—is essential
11. The best architectures, requirements and designs emerge from self-organizing
teams
12. Agile processes promote sustainable development – Sponsors, developers and
users should be able to maintain a constant pace indefinitely
30. XP Values
30
Communication: Building and disseminating institutional knowledge among members
of the development team. Helps developers have a shared vision. Happens through
collaboration between users and developers, frequent verbal communication, and
feedback, simple design, common metaphors.
Simplicity: Start with a simple solution. Extra functionality can be added later.
Feedback: Feedback looked in three dimensions : Feedback from the system,
Feedback from the customer and feedback from the developers.
Courage: Developers feel comfortable with refactoring, knowing when to throw away;
courage to remove source code when obsolete
Respect: Respect for other as we as self-respect. For example, developers should
never commit changes that break compilation, that makes existing unit tests fail, or
that otherwise delays the work of their peers.
31. Feature Driven Development (FDD)
• Starts with a Domain Object Model and focus on OO
• Developed on real systems of Scale
• Eight Practices
1. Developing by Feature
2. Class Code Ownership
3. Feature Team
4. Inspections
5. Regular Build Schedule
6. Configuration Management
7. Reporting/Visibility of Results
31
32. Dynamic Systems Development Method
(DSDM)
1. Assume can’t build perfectly first time
2. 20% of time can deliver 80% of proposed system
3. Therefore focus on highest value – sounds like scrum, right?
4. Core practices
5. Time Boxing
6. MoSCoW prioritization
7. Modelling but only at user level
8. Prototyping – helps with understanding and awareness
9. Testing – focused on User no specifics on lower levels of
testing
10. Configuration Management – any increment is reversible 32
33. Agile Methods and Practices
33
http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf
38. SCRUM – How it evolved
38
• Takeuchi and Nonaka – coined in The New Product Development Game in 1986
• 1993 First Project Easel Corp by Jeff Sutherland, formalized by Ken Schwaber and Jeff
Sutherland in 1995
• 2002 Scrum Alliance formed
• It is now probably the fastest-growing approach to software development globally
• Used in many Fortune 100 companies globally
• Google • Sun
• Infosys • Wipro
• TCS • IBM
• Nokia • Lockheed-Martin
• HP • Agilent
• EMC • GE
39. SCRUM Definition
39
“ An agile framework that allows us to focus on delivering the highest
business value in the shortest time”
Mike Cohn
40. What is SCRUM?
40
• Incremental and Iterative
• High Level - Not prescriptive – although there are boundaries
• Emphasis on Collaboration
• Easy to understand – hard to execute
• Change as Opportunity
• Goal(s) oriented
• Empirical Process – Inspect and Adapt, Transparency
• Suited to Complex product development – cynefin framework, agile practices still
useful in other quadrants!
41. SCRUM is Not
41
1. Lacking Discipline – Inspection and Adaption, Just in Time Sprint and Release
Planning, XP engineering practices take discipline
2. Gantt chart detailed plan
3. Not a Silver Bullet – each project is different and has differing needs – but stick to the
core values and roles when applying it
42. Why SCRUM became popular
42
• More business value sooner
• Greater visibility
• Improved productivity and Discipline
• Less waste
• Higher quality
• Stronger teams with better morale
• Better return-on-investment for projects
• Visible Structure
46. SCRUM Challenges
46
• It’s hard!
• It requires significant change
• Change in practices and skills
• Change in organization, planning, budgeting, HR
• Change in mindset and culture
• It makes all dysfunction visible
• Scrum doesn’t fix anything: we have to do it
• If we don’t address the problems, it will be painful
• Bad products will be delivered sooner, and doomed projects will fail faster
• Partial adoption may be worse than none at all
• Be forewarned: many Scrum adoptions fail!
49. The SCRUM Team – Product Owner (PO)
49
• Owns vision for the product to be produced/released
• Creates and maintains the Product Backlog
• Final decision maker on prioritization of Product Backlog items
50. The SCRUM Team – SCRUM Master
50
• Facilitates implementation of the
process
• Builds self-organizing teams
• Removes team’s constraints and
impediments
• Protects the team from external
disturbances
• Empowers the team through Servant
Leadership
• Helps create visible Information
Radiators
• Coaches the team for successful
implementation
51. The SCRUM Team
51
• 7 people, +/- 2 – The Right Size
• Cross-functional team - includes
design, coding, testing, and other
resources required for potentially
shippable software
• Self-organizing and self-managing
• Inspect and Adapt through Daily
Scrum Meeting and Retrospective
• Assist PO to groom the backlog
• Plan the sprint
• Swarm over tasks – minimize Idle
work
• Musketeer attitude
• High bandwidth communications –
Face to Face always best
• Transparent, Focused (no more than 2
tasks), works sustainably, stays
together
53. Agile Project Manager Responsibility
53
Ask the following questions
• How are Agile Projects Managed?
• Is the Scrum Master considered the Agile Project Manager?
• Who handles traditional project management responsibilities?
• Does this Scale?
Agile processes distribute the traditional project manager's responsibilities
• Task assignment and day-to-day project decisions –Team
• Responsibility for scope/schedule trade-offs - Product Owner
• Quality management – Team, Product Owner & Scrum Master
• Other traditional project management responsibilities - One or more of these
roles
55. Agile Teams
55
Staffing
• Team composition and interaction changes.
• Co-location of teams and or collaboration via
communication tools
• Roles and responsibilities of team members are clearly
defined
• Consider the use of an agile coach on the team
56. An Exercise in Responsibilities
56
ROUND 1: In a Non-Agile Environment
TEAM OTHER
PROJECT MANAGER
57. An Exercise in Responsibilities
57
ROUND 2: In an Agile Environment
TEAM OTHER
PROJECT MANAGER
SCRUM MASTER
58. 6 Time-boxed ceremonies
58
Daily Scrum
Sprint
Release
Planning
Sprint
Planning
Sprint Review
Sprint
Retrospective
How are we doing?
How often can we deliver?
What or how much do we do and when?
How do we do it?
How did we do it? Fit for purpose/use?
How do we do better? Inspect and Adapt
A timebox is a fixed period of time, during which something must be done.
59. Duration of Timeboxes
59
Maximum
Duration
For Sprints of 6
weeks
For Sprints of 4
weeks
For Sprints of 2
weeks
For Sprints of 1
week
Release
Planning
1.5 days 1 day ½ day 2 hours
Sprint Planning 1.5 days 1 day ½ day 2 hours
Sprint Review 6 hours ½ day 2 hours 1 hour
Sprint
Retrospective
6 hours ½ day 2 hours 1 hour
Daily Scrum 15 minutes 15 minutes 15 minutes 15 minutes
These are the maximum durations of each timebox. Meetings may adjourn early, if
the agenda is completed before the allotted time
60. SCRUM Artifacts
60
• User Stories
• Product Backlog
• List of functional & non-functional
requirements
• Sprint Backlog
• Prioritized list of stories for a
given Sprint
• Sprint Burndown Chart
• A chart showing completion of
stories over time
• Release Burndown Chart
62. 3 Key Tenets: Deliver-Empower-Adapt
62
1. Deliver Early & Often
Delivering a fully completed increment every time (sprint). This allows
stakeholders to enjoy the business benefits early rather than waiting for
the full life-cycle.
2. Empower your teams
Innovation does not come from compliance. Those doing knowledge
work are best qualified to organize that work. Scrum requires teams to
enforce professional boundaries, so they can achieve results
3. Inspect and Adapt
High performing teams are those that adjust their work to meet the
current reality. Scrum offers both quantitative and qualitative
techniques to assess how we can avoid disaster and improve
performance
64. Defining Lean
64
• Lean is a continuous improvement methodology
focused on managing processes, and improving them by
compressing time, rather than sweating assets
• Application of principles and techniques to eliminate
waste and improve efficiency of the process
• Focuses on flow, the value stream and eliminating
muda, the Japanese word for waste
• It is production of goods using less of everything
• Was generated from the Just-in-time (JIT) philosophy
of continuous and forced problem solving. JIT enables
making components available where they are needed
when they are needed, just at the time when needed.
65. Historical Perspective
65
• Underpinning of Lean Philosophy is that an organization must leverage the
knowledge and brain power of every employee to help the company change for the
better everyday to meet its goals.
• Toyota Production System – 1948 - 1975
• Developed by Taiichi Ohno, Shigeo Shingo and Eiji Toyoda
• Toyota produces automobiles for the general public of Japan
• Implemented JIT based production
• Toyota became one of the top 10 companies in the world
• 2007 - became the largest car manufacturer
• Focused on eliminating three kinds of waste
• Muri
• Mura
• Muda
66. Types of Waste
66
MUDA
Any activity that consumes resources
without creating value for the customer.
Unneeded processes or steps:
• Using expensive tools instead of simpler
ones
• Having meetings when not required
• Excessive paperwork
• Duplication of work
MURA
Unevenness, irregularity or Inconsistency in an
operation
MURI
Overburdening of equipment, facilities, people
caused by Muda and Mura Pushing people or
equipment beyond allowed limits
68. The 7 Wastes
68
Wastes in
Manufacturing
Wastes in Software
Development
Inventory Partially Work Done
Extra Processing Paperwork or extra
documentation
Over Production Extra Features
Transportation Building the Wrong
Thing
Waiting Waiting for
Information
Motion Task Switching &
Motion
Defects Bugs
69. 7 Principles of Lean Software
Development
69
1. Eliminating waste
2. Build quality in
3. Create knowledge
4. Defer commitment
5. Deliver fast
6. Respect people
7. Optimize the whole
71. Value Stream Mapping
71
• It is the process of identifying and charting the flow of information, processes, and
goods or services across the entire supply chain from the supplier to customer possession
• Includes both value-added and non value-added activities
• Allows for “seeing” areas of waste in current state
• Enables you to remove waste and improve cycle time and efficiency
76. Applying SCRUM to a Sales Scenario
76
• Current Organization Challenges:
• Update on sales opportunities and status updates is weekly and bi-weekly
• Resources are working on low value deals or non-deal closing activities
• Teams losing focus and randomized due to multiple directions
• Reactive decision making leading to delays and lost opportunities
77. Applying SCRUM to a Sales Scenario
77
• Backlog
• Deals to be closed this quarter
• Deals to be developed in the following quarters
• User Story
• Objective goals to be achieved
• Tasks
• Activities identified to achieve the targets
• Impediments
• Challenges / Issues blocking progress
• Release
• Target Sales Volume / Numbers
• Sprint
• Month / Quarter
• SCRUM Master
• Sales Manager
78. Applying SCRUM to a Sales Scenario
78
• List of sales objectives to be achieved forms the Product Backlog
• Developing a quarter by quarter sales plan maps to the Release Plan to get the
product out.
• The immediate quarter’s target maps to the Sprint Plan
• A daily standup meeting of 30 minutes is held with the Sales team to take status
update and discussing impediments, followed by another 30 minutes of prioritization
discussion
• The Sales Manager acts as the SCRUM master during the Standup Meeting to help his
team by removing the impediments and providing them with all the resources and
support. He will also work closely with the management to ensure that the team does
not get randomized and remain focused.
• Embrace change and adapt
• Empower the team to speak-up and communicate and facilitate team decision making.
79. Applying Lean Principles to Construction
Industry
79
Lean Construction is an adaption of Lean principles and practices to design and execution of
construction projects. Lean construction supplements traditional construction management
approaches by focusing on:
1. Creating material and information flows
2. Maximizing value generation
3. Using plan, execute and control paradigms
Although Lean Construction shares many principles with Lean Production, it is different in how it is
practiced.
Shared Principles:
1. Optimization of entire system through collaboration and systematic learning
2. Continual improvement and pursuit of perfection involving everyone in the system
3. Focus on delivering value desired by the owner/client/end-user
4. Creating flow by eliminating obstacles to value creation and elimination of processes that create no
value
5. Creating pull production
Differences:
1. Construction projects are unique.
2.Multiple contractors/suppliers act under different commercial arrangements
3.Construction environments are typically outdoors and/or difficult to control
4.Communication challenges caused by teams being geographically separated
81. Creating and Managing a Product
Backlog
81
• A backlog contains a broad list of descriptions of all required features, wish-list items,
etc. prioritized by business value. It is the “What” that will be built.
• It contains rough estimates of both business value and development effort.
• Product Owner is in charge of defining priorities in the Product Backlog
• Maintain Story Lists
87. Principles of User Stories – Types of
Stories
87
Theme:
• A set of related user stories that may be combined together and treated as a single
entity for either estimating or release planning
• A Theme is kept for ease of estimation and planning
• Example: Support for Database will involve defining schema, migrating existing data,
creating reports and so on
Epic:
• Large user stories with low priority and too big to implement in one iteration
• Broken down further into smaller user stories and the lower level child stories are
assigned priorities for planning
• An Epic, by its very size alone, is often a Theme!
89. User Story Example
89
As a customer service rep., I can search for a customer so that I can view his/her
account details.
• When searching by a valid account number, the account is shown
• When searching by a valid name and SSN, the account is shown
• If no results are found, show appropriate message
• Acceptance tests?
90. User Story Attributes - INVEST
90
Every user story (requirement) should meet the below
criteria (INVEST acronym) for it to be considered complete:
• Independent
• Negotiable
• Valuable (to users/customers)
• Estimate-able
• Small
• Testable
91. Non-Functional Requirements
91
• Write a story for them
• They can also become part of the Definition of Done.
• e.g.: Internationalization would affect all stories in some way.
• Other stories
• Knowledge Acquisition Stories – e.g.: explore a new technology, spike solution
• Technical Stories – e.g., set up DB table
92. Gathering User Stories - Workshop
92
• User Story Workshop
Product Owner, Scrum Master and Development Team together with
stakeholders to build detailed requirements
• Story Mapping (Jeff Patton)
• Decompose High Level Activity into a workflow with further
decomposition into tasks
• Divide into a hierarchy of Themes, Epics and Stories
• Workflows are useful even if not doing the technique explicitly
• Natural prioritization can emerge
93. Gathering User Stories – User Story
Mapping
93
Story Mapping (Jeff Patton)
• Decompose High Level Activity into a workflow with further decomposition into
tasks
• Divide into a hierarchy of Epics, Themes and Stories
• Workflows are useful even if not doing the technique explicitly
• Natural prioritization can emerge
94. User Story Smells
94
• Interdependent Stories
• Gold Plating
• Too Many Details (not INVEST)
• Thinking Too Far Ahead (waterfall mindset)
• Language Issues
• Business Dominated – concepts not understood by
Developer
• Developer Dominated – too much technical jargon
95. User Story Splitting
95
• A story may not fit within an iteration, it’s too large to estimate (epic)
• Examples (from Mike Cohn – Agile Estimating and Planning)
• Split by Data Boundary.
• As a borrower, I want to pay off my loan
• As a borrower, I want to pay off my loan without overpayments
• As a borrower if I accidently repay too much, I get a refund if it’s
over 2??
• Split by Operational Boundaries – C.R.U.D.
• Cross cutting concerns, e.g. logging can be another user story
96. Backlog Prioritization
96
Agile Prioritization Technique - MoSCoW
Must have (or Minimum Usable Subset)
Should have
Could have
Won’t have (but Would like in future)
‘Must Haves‘ are features that must be included before the product can be launched. It is
good to have clarity on this before a project begins, as this is the minimum scope for the
product to be useful.
‘Should Haves‘ are features that are not critical to launch, but are considered to be
important and of a high value to the user.
‘Could Haves‘ are features that are nice to have and could potentially be included
without incurring too much effort or cost. These will be the first features to be removed
from scope if the project’s timescales are later at risk.
‘Won’t Haves‘ are features that have been requested but are explicitly excluded from
scope for the planned duration, and may be included in a future phase of development.
98. Velocity
98
Measuring Velocity
Fully “done, done” story points are counted
Partially completed stories do not count at all
• Don’t imply precision by saying you completed 4.7 points out of 8
• That last 10% can take 90% of the time
• The business value is not achieved until it is done, done (or do smaller stories)
The actual velocity of the last two iterations is the planned velocity of the next
100. Agile Estimation
100
• What are some of the traditional techniques you are aware of?
• What are you estimating?
101. Traditional Estimation Techniques
101
• Count/Compute/Judge
• Calibrate & Historical Data
• Individual Expert Judgement
• Decomposition & Recomposition
• Estimation by Analogy
• Expert Judgement in Groups: e.g. Wideband Delphi
Source: “Software Estimation: Demystifying the Black Art” by Steve McConnell
104. Challenges
104
Human Influences can make a 14x difference in total project effort/cost according to
Cocomo II (The Constructive Cost Model)
Eg: 10K LOC
Eg: 10 person months
105. Challenges
105
Size Effort
Schedule
Cost
Features
Eg: 10K LOC Eg: 10 Staff months Eg: 6 months duration
Schedule In Months = 3.0 x Staff months1/3
Need to cater for many overheads
e.g.: holidays, full time/part time, dependencies
106. Agile Delivery – Doesn’t Estimate
Schedule
106
Size Effort
Schedule
Cost
Features
Agile Delivery estimates size in story points or ideal hours & over iterations. Team
capacity and velocity drives schedule.
107. Story Points
107
• Measure of Complexity - A simple way to estimate level of effort expected for a Story
based on size and complexity
• Estimate of Size, not Duration Estimates are based on size, not duration (derived
empirically once Iterations have started)
• Relative Weighting Story points are a relative measure (research has shown humans
are better at this)
• Additive Puts estimates in units that can be added together (unlike time-based
estimates!)
• Constrained to Set of Values Often scored on a scale based on Fibonacci Numbers (0,
1, 2, 3, 5, 8, 13, 20, 40, 100)
108. Planning Poker
108
An iterative approach to estimating Steps:
• Each estimator is given a deck of cards, each
card has a valid estimate written on it
• Customer/Product owner reads a story and it’s
discussed briefly
• Each estimator selects a card that’s his or her
estimate
• Cards are turned over so all can see them
• Discuss differences (especially outliers)
• Re-estimate until estimates converge
110. Planning Poker – Why It Works
110
• Multiple Experts - Delphi Method
• People doing the work are best placed to estimate it
• Generates a lively debate - Consensus
• It’s fun!
• Let’s try it - curiosity
111. Let’s Play Planning Poker
111
• We are having a massive party
• Lots to prepare!
• Want to make a large fruit salad
• Never made one before...
• What can we do in time?
119. Have A Vision
119
• Establish the vision for the product - concise
to the point
• Examples
• Elevator Statement – can you state
the
goal in a 30 second elevator ride
• Product Datasheet – do the one
pager
• Product Vision Box – Draw the box
the
product ships in
• Conference Slides – two, three slides
not bullet points
• Press Release – imagine the press
release you’d create – write it down
• Magazine Review – a fictitious review
of the product
130. Daily Standup (SCRUM) Meeting
130
Goal
• Enable to team to share progress with each other
• Make visible blocks (impediments) daily for whole team to see
Everyone stands in a circle and reports 3 things
• What did I do since the last Daily Scrum Meeting?
• What will I try to do by the next Daily Scrum meeting?
• What are my blocks?
15 minutes maximum
No discussion or debate: listening only
• After meeting ends, discuss and problem-solving can start
Team and ScrumMaster only
• Team can invite PO or others if they wish, but it’s up to the team
After the meeting, ScrumMaster leads the removal of blocks
131. Information Radiator
131
• Was coined by Alistair Cockburn
• Graphical Representation of Project Status & Key aspects displayed in Team
Workspace
• Current iteration’s work set ( user stories)
• Current work assignments
• Number of tests written, passed, failed
• Number of user stories delivered
• Status of key servers
• Results of actions from previous retrospective
• Keeps team focused on tasks and actions needing priority and attention
• Helps drive transparency across the organization
138. Techniques for Sprint Retrospective
138
• Post-it brainstorming
• Dot voting
• Timeline
• Team Radar
139. Sprint Retrospective – An Example
139
Suggested Topics
• What went well, What could be better,
What will we do about it
• What should we continue doing, What
should we start doing, What should we stop
doing
Suggested Tools
• Whiteboards, Flipcharts, Index Cards, Sticky
Notes
Team mind-map exercise to understand relationships of project issues
142. Best Practices
142
Easy and continuous access to resources
• Source code repository (Bitbucket, Github, etc)
• Continuous Integration Server (Jenkins, Bamboo, etc)
• Bug Tracking tool (JIRA, Bugzilla, etc)
• Wiki (Confluence, etc)
• Project Management Tool (JIRA, etc)
Setup infrastructure to support team member communication
• Sprint meetings
• Offline discussions
• Knowledge sharing sessions
Regular people movement for short periods
• Mixing of people to overcome cultural issues, etc.,
• One Team feeling
143. Making Agile Adoption Successful
143
• Use a Physical Board or Good Software
• Start collecting and using statistics
• Engage a coach / consultant
• Action over talking
• Give everyone training and start group-wide discussions
• Enthuse, Pull, don’t PUSH
• Be clear on Why
• Process and Technical , adopt technical side as well as process side
• Get Product Management / Owner Flow to developers clear and clean
• Structure changes – Functional groups
144. SCRUM in Action
144
Scrum Meetings
• Sprint Planning
• Daily Stand Up
• Sprint Review
• Sprint Retrospectives
Co-Located Teams
• Easier communication &
collaboration
• Sprint execution comparatively easier
Distributed Teams
• Teams with some overlapping time
period
• Teams with no overlapping time
period
145. Watch the Live Demonstration
Watch the recorded webinar here!
146. Recommended Courses
NetCom Learning offers a comprehensive portfolio for Agile Project
Management training options. Please see below the list of recommended
courses:
Agile Project Management
Managing Agile Projects Using TFS 2017
PMI Agile Certified Practitioner (PMI-ACP)®
Check out more Agile Project Management training options with NetCom
Learning – CLICK HERE
147. Our live webinars will help you to touch base a wide variety of IT, soft skills and
business productivity topics; and keep you up to date on the latest IT industry trends.
Register now for our upcoming webinars:
5 Practices of Exemplary Leadership – May 04
A Deep Dive in the World of IT Networking (Part 1) – May 09
How to Manage & Secure Data with Microsoft Datacenters?- May 11
VMware vCenter 6.5 Consoles and Connections – May 15
Office 365 on any Platform (Windows, Mac, Mobile/Tablet) – May 18
148. Special Promotion
Whether you're learning new IT or Business skills, or you are developing a learning plan for
your team, now you can register for our Guaranteed to Run classes with confidence.
From Microsoft, to CompTIA, to CISSP; all classes delivered by top-notch instructors in in-
person Instructor-led Classroom or Live Online.
Learn more»
149. To get latest technology updates, please follow our social media pages!
150.
151. THANK YOU !!!
We manage learning.
“Building an Innovative Learning Organization. A Framework to Build a
Smarter Workforce, Adapt to Change, and Drive Growth”. Download now!