Lifting the Language Barrier
“If you differ from me, my brother, far from harming me, you enrich me.” – Antoine de Saint-Exupéry, aviation pioneer, writer and poet, 1900 – 1944
Over more than three decades working internationally as an engineer, project manager, trainer and coach, one of the major things that I have observed is the importance of the language barrier, particularly from a “Discounting level 1 & 2” point of view.
As a reminder, here are the Transactional Analysis Discounting levels again (from the previous blog post):
- Not registering that a problem exists
- Not registering the significance of that problem
- Not registering that there are options for action [to solve the problem]
- Not registering that one is personally capable of implementing those actions [to solve the problem]
We also identified three main barriers to effective virtual global teamwork:
- Language barrier
- Distance / time zone barrier
- Human aspect / cultural barrier
Today, we will concentrate on the language barrier. We will run it through Discounting Analysis, moving from problems to solutions. We will also take a step further and leverage advantages to enhance effectiveness.
Our aim is to evaluate our proficiency and that of our counterparts. We can then make any needed improvements to our own techniques and, as Project Managers, help team members and other stakeholders to progress in proficiency.
The Language Barrier
Levels 1 & 2 – Problem and Significance
To work together, we need to communicate, to “speak the same language”. Yet, around seven thousand languages are used around the world today.
Over time, we have found solutions to this problem. The use of a lingua franca is one. In order to understand each other, the contemporary use of English is common in international communication. And that is the trap! Thinking that (a) speaking English solves all problems and (b) those who do speak English truly understand each other!
- Only around 20% of the world’s population speak English (as a first or second language). This distances 80% of potential co-workers. The significance of this problem is clear.
- A more subtle problem exists: registering issues between users of English. Of the global 20% of English speakers, around one-fifth speak English as their first language. For the other four-fifths, English is a secondary language or is present in their country. For less-proficient practitioners, it is obvious that care must be taken to ensure correct communication when using English internationally. However, amongst fluent practitioners, frequently no such caution is observed. International audio meetings filled with, “full speed ahead”, jargon-rich English spoken with strong accents are common. Less fluent participants try hard to follow, with difficulty. It is often clear that some practitioners have not registered that a problem exists. “This meeting is in English, we are speaking English, so there’s no problem, right?” Unfortunately, very, very wrong!
The cultural/personality iceberg – above and below the waterline
Above the waterline, we see the “what”. Observable issues of international communication are often in plain view: puzzled expressions, mistakes, incomprehension and unexpected/unwanted deliverables, sometimes months later, are common.
Below the waterline lies the “why”. We would all like to communicate using English confidently and with ease. However, if we subjectively judge that our level of English is “inadequate”, we may be tempted to stay silent to hide our self-perceived “incompetence” and “save face”. The importance of “saving face” is particularly important in certain cultures. “Low-face-importance” cultures assume that anyone not understanding will interrupt to clarify. “High-face-importance” cultures assume that it is clear that doing so would induce a loss of face and is therefore not a viable possibility…
Levels 3 & 4 – Options and Actions
When using English to communicate:
- We use easy words and short, clear sentences. The simpler, the better
- We articulate clearly and take our time to speak. We use full words rather than joining two words together: “I am an engineer” is clearer than “I’m an engineer”
- We use Latin root verbs instead of Germanic root verbs: “I will obtain the contract” is clearer than “I’m going to get the contract” for many non-native English speakers
- We borrow best practices from international aviation communication:
– we use the international alphabet (alpha, bravo, charlie, etc.) to spell-out difficult words
– we use individual digits to clarify numbers: “one-four” is clearer than “fourteen”
– we confirm key elements by repetition: Person A: “Please supply fourteen (one-four) samples tomorrow.” Person B: “We will supply fourteen (one-four) samples tomorrow.” - We use regular pauses and “sign posting” to allow speaking partners to easily follow the conversation: “I will now talk about X / [I deliver message X] / “I have talked about X and will now talk about Y” / [I deliver message Y]
- We prefer nouns to verbs: “Who is your Manager?” is easier to understand than “Who do you work for?”
- We avoid phrasal verbs: “call off”, “go back” and “shop around” – completely confusing!
- We avoid question-tags: “you do understand, don’t you?” – even more confusing!!
- We are careful with humour as cultural norms for humour in business vary widely. A well-intentioned humoristic comment may be misunderstood and cause unwanted confusion. It may also produce a negative effect for cultures for which the norm is to keep humour for outside of office hours…
- Most importantly, all nationalities, particularly native English speakers, must make efforts to adapt their speech with the one common goal of facilitating mutual understanding
When some parties have a very basic level of English (or do not speak English at all):
- Support from a professional translator/interpreter is of great value, allowing swifter communications and fewer expensive misunderstandings and mistakes. Language support from multi-lingual colleagues is also useful. When using translation/interpretation software, we are aware of the risk of incorrect translations
- A picture is worth a thousand words! Images, drawings and sketches boost mutual understanding
- Written communications allow time for translation and understanding. They can, however, lead to “conversations” which take many days and still end in confusion
- A way to improve on this is to write and talk at the same time: during an audio meeting, as one is speaking, one writes key words and figures on-screen to provide anchors for understanding
- We plan regular follow-up meetings: daily status points to check that progress made is according to understandings. This allows misunderstandings to be identified and corrected early
For all interactions:
- We reduce “loss of face” risks by clearly stating our aim of mutual understanding and the use of “less-than-perfect English” as the communication norm
- We reinforce openness by allowing time for people to build relationships and confidence
- We continuously monitor speaking partners to detect non-verbal signs of confusion or disagreement
- We ensure that all people contribute to the conversation by bringing in members with a tendency to stay silent (perhaps due to a difficulty to interrupt to enter the conversation)
- For important decisions, a written record of agreements is made during the conversation, in real-time. Participants confirm and approve the record post-meeting.
Building Strong Foundations
Our efforts to address the language barrier will obviously bring immediate benefits in improved understanding between global team members. Also, as a collateral benefit, the care, energy and good will that we transmit through our efforts to understand and be understood will be noticed by our counterparts. This tangible good will builds trust and good working relationships, particularly between cultures and at a distance.
We will build on this strong foundation in the next and final blog focused on the distance barrier and human aspect/cultural barrier.
Until then, take care and don’t hesitate to share your experiences or highlight any questions.
Peter
For further details, see “Foolproof International Communication”, Moberg & Chadwick, Japco Publishing House 2013, ISBN 978-91-637-1116-9, 2013
About the Author
Peter Chadwick is the Founder of Island Hoppers, and a Trainer and Consultant with IIL. He is qualified as an engineer, project manager, trainer, coach and pilot.
The common threads to Peter’s career are innovation and exploration. From early days dreaming-up designs, through roles leading larger and larger international project teams, up to his current role of trainer and coach, Peter constantly searches for better designs, better ways of working.
Building on his research and in-the-field experience, he has co-authored two books on transcultural cooperation with Pia Moberg and devised the Chadberg Model.
Peter has a long track record of designing and facilitating pragmatic support to individuals, teams and organisations – harnessing the power of international collective intelligence.
Can the Words "Innovation" and "Project Management" Be Used In The Same Sentence?
By Harold Kerzner, Ph.D. | Senior Executive Director for Project Management, IIL
INTRODUCTION
Companies need growth for survival.
Companies cannot grow simply through cost reduction and reengineering efforts.
Companies are recognizing that brand loyalty accompanied by a higher level of quality does not always equate to customer retention unless supported by some innovations.
According to management guru Peter Drucker, there are only two sources for growth: marketing and innovation [Drucker, 2008]. Innovation is often viewed as the Holy Grail of business and the primary driver for growth. Innovation forces companies to adapt to an ever-changing environment and to be able to take advantage of opportunities as they arise.
Companies are also aware that their competitors will eventually come to market with new products and services that will make some existing products and services obsolete, causing the competitive environment to change. Continuous innovation is needed, regardless of current economic conditions, to provide a firm with a sustainable competitive advantage and to differentiate themselves from their competitors. The question, of course, is “How do we manage innovation needs?”
INNOVATION AND PROJECT MANAGEMENT
For years, there has been a debate as to whether the words “innovation” and “project management” should be used in the same sentence. Some researchers argue that project management and innovation management should be treated as separate disciplines.
Innovation requires:
- An acceptance of significant risk, more so than in traditional project management
- A great deal of uncertainty
- A focus on strategic goals and possibly no business case exists
- Unknown constraints and assumptions that continuously change
- Decision making in an unfamiliar landscape
- A creative mindset
- Collaboration across all enterprise organizational boundaries
- Significant interfacing with customers in every market segment
- A different leadership style than with traditional project management
- A set of tools different than what is being taught in traditional project management courses
Some tools typically used when managing innovation include:
- Design thinking
- Storytelling
- Decision-making flow charts
- Value proposition
- Business model thinking
- Wall of ideas with post-it notes
- Ideation
- Prototyping, perhaps continuously
Innovation management, in its purest form, is a combination of the management of innovation processes and change management. It refers to products, services, business processes, and accompanying transformational needs, whereby the organization must change the way they conduct their business. The change can be incremental or radical.
Project management practices generally follow the processes and domain areas identified in the Project Management Institute (PMI)® A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Strategic innovation follows other processes such as strategizing, entrepreneurship, changing and investing [de Witt & Meyer, 2014].
But now, companies are realizing that innovation strategy is implemented through projects. Simply stated, we are managing our business as though it is a series of projects. Project management has become the delivery system for innovation activities, but the integration is complex and varies with the type of innovation project.
PROJECT MANAGEMENT IS A BUSINESS DELIVERY SYSTEM
Today’s project managers are seen more so as managing part of a business than managing just a project. Project managers are now treated as market problem-solvers and expected to be involved in business decisions as well as project decisions. End-to-end project management is now coming of age. In the past, project managers were actively involved mainly in just project execution with the responsibility of providing a deliverable or an outcome. Today, with end-to-end project management, the project manager is actively involved in all life-cycle phases including idea generation and product commercialization.
For decades, most project managers were trained in traditional project management practices and were ill-equipped to manage innovation projects. Today, attempts are being made to integrate all of this into a single profession, namely innovation project management (IPM).
PROJECT MANAGEMENT LITERATURE
There exists a plethora of literature on project management. Unfortunately, most of the literature focuses on linear project management models with the assumption that “one size fits all.” While this may hold true in some industries and for some projects, the concept of “one size fits all” does not apply to projects involving innovation. Innovation varies from industry to industry, and even companies within the same industry cannot come to an agreement on how innovation management should work.
The situation gets even worse when companies try to use traditional project management for business processes such as business model innovation, where you have the greatest degree of risk and uncertainty, where traditional risk management planning will not work, and where a great deal of flexibility is needed for decision making. Different project management approaches, many requiring a higher level of flexibility, will be dictated by the level of technology, the amount of product versus product changes, and whether the impact is expected to disrupt the markets.
Project managers need flexibility in their ability to select the appropriate tools for their projects and customize the processes to fit the needs of the projects. This holds true even for those projects that do not require innovation. The future will be flexible project management models such as those used in Agile and Scrum projects.
“Managers need to recognize the type of project at the start, resist institutional pressure to adapt traditional ‘rational’ approaches to all projects and apply an appropriate approach – one tailored for the type of project” [Lenfle & Loch, 2010]. Traditional project management does not distinguish between types of projects. Articles are appearing in literature that propose a methodology to classify projects to guide the design of a suitable project management model [Geraldi et al., 2011].
We have learned from Agile and Scrum that flexible project management approaches are necessary for many projects. This same thinking will be required for innovation projects. We will need different tools and different skill sets than most project managers currently use.
Have a question for Dr. Kerzner? Leave your comment below.
About the Author
Harold Kerzner (M.S., Ph.D., Engineering, and M.B.A) is IIL’s Senior Executive Director for Project Management. He is a globally recognized expert on project management and strategic planning, and the author of many best-selling textbooks including Project Management: A Systems Approach to Planning, Scheduling, and Controlling and Project Management 2.0. Dr. Kerzner has previously taught project management and business administration at Baldwin-Wallace University, engineering at the University of Illinois and business administration at Utah State University. He obtained his industrial experience at Thiokol Corporation where he held both program management and project engineering responsibilities on a variety of NASA, Air Force, Army, Navy and internal R&D programs.
REFERENCES
Drucker, P. F. (2008). The Essential Drucker. Reissue Edition, Harper Business, New York.
Witt, B. de, & Meyer, R. (2014). Strategy: An international perspective, Cengage Learning EMEA, Andover.
Lenfle, M. & Loch, C. (2010). Lost roots: How project management came to emphasize control over flexibility novelty, California Management Review, 53 (1), 32 – 55.
Geraldi, J. G., Maylor, H. & Williams, T. (2011). Now, let’s make it really complex (complicated): A systematic review of the complexities of projects. International
Journal of Operations & Production Management, 31 (9), 966 – 990.
PMBOK and PMI are registered marks of the Project Management Institute, Inc.
Project Managers Need to Focus on the User Experience – Their Own!
By J. LeRoy Ward, PMP, PgMP, PfMP, CSM, CSPO | Executive Vice President – Enterprise Solutions, IIL
Odd title, I know. What does it really mean? Let me phrase it as a question:
What’s it like to work with, or for, you? In other words, what’s the “experience” you provide to “users” when they engage with you?
Today, UX, or user experience, is of paramount concern among product manufacturers and service providers. Take Amazon, for example. As a Prime User, the UX of logging on, ordering, and receiving products within two business days (here in the U.S.) is almost “frictionless” as they like to say. It’s quick, easy, and accurate.
Returns? Not a problem. Tracking an order? Piece of cake. Delivery to my mailbox (or door if the package is too big)? The United States Postal Service has it down pat, and they even deliver on Sundays! That’s the UX that Amazon provides its customers.
But UX is also key in service delivery as well. Checked into a hotel recently, or rented a car, or went to the grocery store, or went to the bank? What was that like? What technologies have these industries instituted that made your experience better, faster, or more convenient? Okay, you get the point. Now, let’s turn to you.
What type of UX do you provide to your client? Is it frictionless?
For example, do you:
| Respond quickly to questions or issues? |
| Always have the latest progress information on hand? |
| Anticipate their needs and reach out when required? |
| Share the bad news along with the good so they always know where they stand? |
| Show up on time, prepared for whatever meeting or event is scheduled? |
| Have a positive attitude? |
| Show creativity and flexibility in handling project matters? |
| Conduct your affairs with a high level of integrity and honor? |
| Place the client’s needs above yours or your company’s? |
| Do what you say you’re going to do, and in a timely manner? |
On the Net Promoter Score survey, when asked “Would you recommend [your name here] to a family member, friend, or business colleague?” would your client answer “yes”?
If you can answer yes to all the questions above, including the Net Promoter Score, then your personal UX is at a very high level and you’re doing well. If not, you might want to start thinking about another approach.
What about your team? How would they evaluate your UX as it relates to your relationship with them?
In almost every Project Management 101 course and text where we, as project managers, are advised, if not admonished, to negotiate for the best team members we can find in our organizations, it’s as if there are folks out there who would jump at the chance of being on our team. Just like when you were a kid and you were waiting to be selected for the best baseball team in your local sandlot games.
But are your work colleagues really “hoppin’ from one foot to the other” waiting for you to negotiate hard to get them on your team? It depends. It depends on how you treated them the last time they were on your team.
I have always counseled project managers to ask themselves one key question regarding team members. “Why would anyone want to be on your team?” One thing I always did on projects was to meet with each team member individually and ask them what they wanted to get out of working on this project. If I could help them meet their goals I did; if not, I’d let them know.
At least they knew I was making an attempt to help them grow professionally. But that’s not all of course. Treating people with respect is just table stakes in this era. People want to have fun, be creative, and come to work excited about making a difference. If you can provide that type of environment, your UX will be off the charts.
How do you know what your UX is? Start by asking your sponsor and manager. Then have some “crucial conversations,” as some pundit once wrote, with those closest to you whom you know will be honest. If you don’t like what you hear, you can start working on those soft skills that really make a difference.
Hitting project “home runs” is not just about meeting deadlines and budgets; it even goes beyond bringing benefits to fruition. It’s making people feel great about their experience working with, or for, you.
In the end, as another maxim puts it, “people may never remember what you did, but they will always remember how you made them feel.”
That’s your personal UX. Make it the best it can be.
Ready to improve your personal UX? IIL can help. Take a look at our Business Skills courses, or request a free consultation.
J. LeRoy Ward is a highly respected consultant and adviser to Global Fortune 500 Corporations and government agencies in the areas of project, program, and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs.
What is Project Management?
By J. LeRoy Ward, PMP, PgMP, PfMP, CSM, GWCPM, SCPM | Executive Vice President – Enterprise Solutions, IIL
What do the Panama Canal and the development of the Boeing 787 Dreamliner have in common?
At first glance, you might say “absolutely nothing.” But, they have a lot in common. Both were the outcomes of projects. And although vastly different in every respect, the Panama Canal, and the Boeing 787 share two characteristics:
- Each is unique. There’s only one Boeing 787 Dreamliner and there’s only one Panama Canal.
- Each is the result of a temporary endeavor. In short, each had a definite beginning and an end.
Once completed, of course, the Panama Canal became operational, and once developed, the Boeing 787 went into service with many more being manufactured as I write this. In short, the design and construction of the Panama Canal, and the design and manufacture of the Boeing 787 were projects.
And these projects were led by competent and highly trained individuals, appropriately named Project Managers, who applied knowledge, skills, techniques, and tools, to all the project activities to produce the end result that met the requirements. That’s called Project Management.
Let’s get a bit more formal. According to the Project Management Institute’s (PMI)® A Guide to the Project Management Body of Knowledge (PMBOK® Guide), project management is defined as “the application of knowledge skills, tools, and techniques to project activities to meet the project requirements.“
Projects have been around for thousands of years. Ever see a picture of the Pyramids of Giza? That’s a project. How about the Great Wall of China? Yup, another project. What about the International Space Station? You guessed it…another project.
Projects come in all shapes and sizes. Have you planned a summer vacation lately? Well, that’s a project. And, how about all those home “projects” that take up our evenings and weekends? The name says it all, doesn’t it?
What are you doing at work these days? Are you working with a group of folks to get a particular product to market, developing a new app, or launching a marketing campaign? If you are, you’re working on a project. Projects are everywhere.
As projects become larger and more complex we break them down into various phases such as Initiating, Planning, Executing and so forth. Every industry has their project “life cycle” as it’s called. We do so because it’s a lot easier to estimate and control our work when we break it down into pieces, rather than trying to grapple with the whole thing at once.
We might even use certain sophisticated tools to help us schedule our project, or analyze risk to avoid trouble. All these activities are part of project management.
If the work you’re doing conforms to the two characteristics above, guess what, you’re working on a project, whether you call it that or not. And, the activities you’re engaged in to get the job done successfully is called project management. Finally, if you’re “leading the charge,” you’re the Project Manager.
So, welcome to the wonderful world of projects and project management. You’re in good company because there are millions more just like you – people who are working on projects every day, and may not have knowledge of formal project management methods. Take the next step by exploring our other blog posts on Project Management, and enrolling in introductory Project Management course from IIL.
J. LeRoy Ward is a highly respected consultant and adviser to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs.
Managing Virtual Teams Successfully
By Dr. Willis H. Thomas, PMP, CPT
Virtual teams are becoming more of the norm for organizations as they strive to acquire the best talent from anywhere in the world, minimize overhead everywhere on the earth and stretch their global presence on a worldwide basis.
Building High-Performance Teams necessitates that we utilize innovative tools and techniques to engage the audience. A study from MIT Sloan found “dispersed teams can actually outperform groups that are co-located teams, provided the right type of collaboration is in place.
As virtual teams move through the typical stages of team development (i.e., Tuckman model of forming-storming-norming-performing), they can benefit from a Simple Interactive Meaningful Practical Learning Exercise (SMILE).
Some may think of these engaging activities as games; however, while they are intended to be fun, the benefits should not be underestimated in terms of the potential positive impact they can have on team performance.
Two outcomes should be considered in the following examples:
- Quantitative Perspective
- Decreasing employee turnover
- Reducing job-related and personal stress
- Increasing job satisfaction
- Enhancing team relationships
- Sustaining motivation through the number of reported productive hours
- Qualitative Perspective
- Improving problem-solving skills
- Inspiring creative thinking skills
- Encouraging critical thinking capabilities
- Strengthening interpersonal skills
- Minimizing negative team conflict
As a Certified Performance Technologist (CPT), I have come to look at the value that SMILEs can have on teams from the perspective of Return on Investment (ROI) and Return on Quality (ROQ). First let’s keep the concept of ROI basic, which is in this context:
Applying this equation to a real-life example, if the cost for rolling out a SMILE activity = $10,000 and the estimated value of the program is $100,000 (considering quantitative and/or qualitative factors such as listed above):
This number is not exaggerated. For example, Malcolm Baldrige ROI has been computed as high as 700%. So considering that SMILE activities have a no cost to low-cost proposition, the computed ROI will typically be very high. This provides justification in allowing the virtual team to participate in the activity. SMILE cost may also take into consideration the amount of time that people are spending on developing the “gaming activity” during work hours as well as participating in it. So COMMON SENSE should be at the forefront to manage the perception of how these activities are facilitated.
The premise is that if it is worth doing, it is worth measuring. The COMMON CENTS philosophy means:
- C = Calculate
- E= Every
- N= Necessary
- T=Teaming
- S=Situation
The bottom line is not only a financial measure, but we also need to consider the non-monetary benefits. ROQ takes into account the Cost of Quality (COQ) — prevention and appraisal costs. In this context, PREVENTION cost refers to the expense that is incurred to prevent defects, errors or a lack of desired performance; whereas APPRAISAL cost, or INSPECTION cost, is the expense incurred to identify defects, errors or lack of performance. To this end, expenditures that are reviewed to ensure that a team will function optimally might include factors such as:
- Web-based platforms for collaboration, i.e., WebEx or GoToMeeting
- Webcam equipment for real-time video conversation
- Shared drive storage for document access
Evolution of Learning Exercises for Collaboration
No one author or source can take credit for the evolution of learning exercises for virtual teams. Online gaming collaboration can be traced back to the introduction of the personal computer and software developers and came to life in the early 1990s when the Internet was introduced. Telecommunications also ran a parallel track, but slightly earlier when McGraw-Hill introduced Games Trainers Play (Newstrom and Scannel, 1980) and 201 Icebreakers (West, 1997). These McGraw-Hill publications refer to Experiential Learning Exercises, group mixers, warm-ups, energizers and playful activities.
Types of Interactive Exercises
There are a variety of interactive exercises that a virtual team can participate in such as:
- Board Games
- Video Simulations
- Role Plays
- Quizzes
- Get-to-Know
- Research
- Trivia
- Ice-breakers
- Virtual escape rooms
- And much more…
The investment a team will make in a SMILE will vary based on the following factors that can be thought of in terms of the competing demands:
- Cost: How much it will be to finance, i.e., one time vs. license fee if applicable
- Time: Length of time of the activity
- Scope: Frequency – how often
- Quality: Complexity – how challenging
- Risk: Uncertainties that may be encountered in implementation
- Resources: Number of participants, software, and systems required, facilities, etc.
Here are some examples of SMILEs that I began to create in 2004 in conjunction with my dissertation that focused specifically on project management. (These examples are referenced on my academic website at http://lessonslearned.info on the Support tab.)
Later, my dissertation topic would be condensed into a book titled The Basics of Project Evaluation and Lessons Learned that won the 2012 Project Management Institute (PMI)® Cleland Award. Since that time, I have delivered speaking engagements on an international basis that discuss concepts from this book.
Example: Transferring Essential Lessons Learned
This Monopoly-style game enables the card deck to be customized with lessons learned. It supports up to 10 players to share lessons learned (i.e., agile retrospectives). This SMILE with the source code is made freely available with the purchase The Basics of Project Evaluation and Lessons Learned.
Taking Great Concepts and Creating a SMILE
In this example, I will look at Grateful Leadership by Judy Umlas. She is a recognized author that discusses how to use the Power of Acknowledgment to “Engage All Your People and Achieve Superior Results.”
Whenever SMILEs are associated with acknowledgment, it can create wonderful fireworks. In this example, the objective is to drive performance through recognition. A survey could be created that drives a visual dashboard of all team members participating in a specific initiative. As feedback is received, the dashboard displays the status of performance in real-time. Examples of how this could be used are solution centers (also referred to as help desks).
Solution Center Performance Example
In the above example, using this dashboard could allow stakeholders to change their ratings on demand; hence affecting the dashboard. A prize (i.e., $15 lunch gift certificate at a popular restaurant) could be associated with the highest score at the end of the month.
SMILE Development Tools
Getting started with SMILE should be easy; however, it should also allow for growth and challenges to keep it interesting. Most of the things that need to be created can be done with Microsoft Office, i.e., Word, PowerPoint, and Excel. For the dashboard example above, this will require macros in Microsoft Excel. For the TELL example above, this will require knowledge of HTML. For those over-performers, they may even consider developing an app that can run on an iPhone and Android platform. The key here is to make it engaging and enjoy the process as you enhance virtual team collaboration.
About the Author
Willis H. Thomas, PhD, PMP, CPT has worked for large corporations and academic institutions in the areas of human resources, learning and development, quality assurance, project management, sales and marketing, measurement and evaluation, and operations.
He has been in senior management for life sciences companies for the past 15 years. Dr. Thomas is a member of adjunct faculty at the Lake Forest Graduate School of Management, International Institute for Learning and Institute of Validation Technology.
His publications have received global recognition from associations such as the Project Management Institute (PMI) where he received the Cleland Award for “The Basics of Project Evaluation and Lessons Learned.” This book was an 8-year effort that enhanced the framework for the evaluation of projects using the PMBOK® Guide.
He has been a featured speaker on an international basis and has received the Apex Publication Excellence Award for implementing useful tools for project management, evaluation and training.
The Benefits of Agile and Scrum
By John Carrington, AgilePM® Practitioner and Trainer, CSM, PRINCE2®, LSSBB
Today, many organisations are experiencing the benefits of an Agile approach. But why all the fuss? What is Agile actually offering to the teams using it?
Let’s start with how and why Agile came about. In 2001, 17 Software Developers met in Snowbird, Utah. They recognized that the way being used to deliver software in projects was not working and software developers typically burnt out in their careers.
Teams would be working all hours to deliver on commitments given at the beginning of the project, which could no longer be met due to changes encountered along the way, like the customer changing their mind or things coming to light that hadn’t been planned for. The pressure of delivering using traditional methods meant that life as a software developer in the 80s and 90s simply could not be sustained. They needed to find a way that people could work and deliver software at a sustainable pace and keep going in their chosen careers, past the age of 40! The Agile Manifesto was born.
According to the 2016 VersionOne State of Agile™ Survey:
- 87% of respondents reported being better able to manage changing priorities after implementing Agile.
- 85% said they had increased team productivity.
- 84% reported improved project visibility.
So let us not forget the reason Agile came about in the first place: to improve the daily lives of the team.
Agile helps teams adopt and continue habits which produce regular, consistent results at a sustainable pace of delivery.
One of the benefits of doing that, over the long term, is the longevity of team members’ careers.
Businesses are often attracted by the better, faster, cheaper benefits — and the teams delivering software benefit by becoming self-organized, high performing teams.
In traditional approaches to managing projects, the time when commitments are made and milestones are confirmed is at the beginning of the project in the planning phase. At that point, delivery dates are far enough away for everyone to be comfortable in their commitments.
The problem with this approach is that the beginning of the project is the time when the development team knows the least about the solutions the team is building, but it is also the time when plans are formed, dates are committed to, and deadlines are set. So they don’t know at this stage which problems may surface and what investigation work will need performing. In other words, they don’t know what they don’t know.
Scrum is one of a number of Agile frameworks that encourages ceremonies or events at various points in the sprint which is the time allocated to development work. These ceremonies enable the team to adopt working practices, like regularly reviewing the work with the customer, and retrospectively looking back at how the team performed in respect of the framework, which facilitate iterative and incremental development.
For example, the 15-minute Daily Scrum is a meeting for the team to update each other on progress, to ensure they are on target to meet their commitment of the Sprint Goal and to ensure there are no blockers.
You don’t need more than 15 minutes to do this, but new teams tend to overrun, which means people stop attending because they take too much time up and it becomes “Anti-Scrum.” This is a clear example of where “doing Scrum” because the guide says we need a daily meeting and “being Agile” are in direct contrast, as approaches.
Scrum can help teams to adopt Agile ways of working by providing enough rigour and discipline in the form of ceremonies/events, roles and responsibilities and artefacts for those teams to develop strong habits of working with Agile practices.
By sticking to the somewhat rigorous Scrum Framework, Agile teams learn good habits and develop a sustainable pace, working to their own commitments rather than to a schedule defined and managed by someone else.
Agilists are generalising specialists… Scrum teams are the “Special Forces” versions of software development teams because they are multi-skilled and cross-functional – small enough to have all of the skills they will need but not too large so they remain agile.
In fact, the special forces analogy continues because in Agile, we talk about “T-shaped” teams where team members have more than one skill, just like in special forces patrols. If one team member of a special forces patrol becomes unavailable, then the idea is that the whole team is not compromised.
In Agile teams, whilst the situation is less “life and death” (although it does not feel like it sometimes!) team members are cross functional so that we limit the amount of times we need to go outside of the team to get the work done. The other benefit is that we continuously learn and improve from each other and as a team.
It’s a Brave New (Agile) World
As we look at the job market over the coming months, we are likely to see more permanent and contract roles specifying Agile skills and there is certainly great opportunity to be realized with those with Agile and Scrum qualifications. That being said, many traditional roles are not, at first glance, part of the Agile vision, so Project Managers, Business Analysts and others are naturally wondering where they fit in.
Many larger organizations are experiencing transformations at the moment and businesses of all sizes are trying to figure out how Agile works at scale. We are seeing job postings for hybrid roles such as Scrum Master/Project Manager and Agile Business Analyst, Agile Delivery Manager, and Agile Coach/Scrum Master as the job market struggles to understand the roles and the differentiated responsibilities within an Agile environment.
Part of this momentum will be a natural restructuring of hierarchy, a necessary re-organizing of roles (both in title and responsibility) and recruitment campaigns that bridge the gap between the hybrid approaches of the early Agile adoptions and take the job market through to the required level of understanding of permanent and contract roles.
Until both organisations and recruitment agencies truly understand what it means to be Agile, we are likely to see more of these “hybrid” roles until organisations catch up with their own transformations. The job market is likely to see lots of changes in the near future whilst the changes that large organisations are making by transforming to Agile approaches filter through to their talent acquisition efforts.
Take this opportunity to ensure you have the key Agile skills that these businesses are going to need to give yourself the optimal chance of getting that next position!
More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.
Ready to improve your Agile skills? IIL can help. Browse our Agile and Scrum courses. If you have a team to train, request a free consultation.
[trx_infobox style=”regular” closeable=”no” icon=”inherit”]
About the Author
John Carrington (AgilePM® Practitioner and Trainer, CSM, PRINCE2®, LSSBB) is an experienced consultant, well versed in all aspects of the Agile project lifecycle and program management, with over 20 years of experience in corporate businesses. John has been involved global software implementations, business transformations, and change projects. John is an excellent communicator with strong influencing skills and a passion to deliver the highest quality outcomes, on time and within budget.[/trx_infobox]
Agile Retrospectives: A Tool for Team Learning
By Luis Gonçalves | Co-founder of Evolution4All, Founder of ScrumMaster Growth
An Agile retrospective is an effective tool used at the end of every iteration to analyze the team’s performance during the project.
Team members gather to review what worked well and what did not so they can improve their performance on future projects.
For companies that are unfamiliar with retrospectives, there are tools and exercises they can use to make the sessions run more smoothly:
- The Sailboat exercise uses illustrations to identify the strengths and weaknesses. In the diagram, the team is the boat while the “worked well” parts are the wind and the “did not work” areas are anchors. Once the team has established what worked and what did not, they can discuss improvements they can make for the next project.
- The Starfish retrospective does not focus on what worked versus what did not. Instead, it uses five categories to address what the team should keep doing, start doing, stop doing, do more of and do less of. The diagram helps the team reflect on varying degrees of success or failure with each part of the project.
- The Happiness retrospective analyzes how the different areas of the project made each team member feel during the project. Each member rates their feelings towards the team, process, and technology as sad, happy, or somewhere in between. Once everyone has inputted their feelings, the group can discuss each area to find improvements for next project.
The Learning Component
Agile retrospectives are a simple yet highly effective way to improve team performance for software projects. Many industry professionals often provide insight or advice on running a great session to make their team work better and improve performance. However, one area of the retrospective that tends to be overlooked is the learning component.
Most retrospective sessions do not create opportunities for the team to learn from their experience. For some, it has become merely a mechanical process and part of the project closing. While the session might generate ideas on ways to improve, it often does not encourage actual learning.
Retrospective Scrums are so much more than just an end-of-project meeting. They are the cornerstone for all inspection and adaptation cycles. While teams should not limit their learning just to the retrospective, the truth is this is where most of the learning occurs. It is the most common place for data mining, or collecting information about the sprint; what happened and the challenges faced.
The learning that can be done during the session becomes secondary to the ideas that are generated by the team to avoid default thinking patterns in future projects. When the focus on agile retrospectives is on the learning, they will always be successful.
Agile Retrospectives with a Focus on Learning
To illustrate this, a Scrum Master recently ran an Agile Retrospective for her team with the focus being on learning. Like most retrospectives, the team looked at the project, provided insight on what worked or did not work, generated ideas to improve performance and then went into the sprint to try the ideas.
Rather than focusing on the outcome of the idea, the team paid attention to the learning that occurred. They ended the process feeling successful because not only did they learn something, but they were able to objectively discuss topics and solutions for improvement.
By creating an environment where the focus is on the learning aspect and not the outcome, the facilitator was able to run a successful session.
In the traditional method, when the focus is more on the outcome, the team may often feel like they failed when they discuss their actions and find their implementations were ineffective because they did not learn anything from the process.
Another example occurred recently when a team tried to work with daily sprints. They met in the morning with the product owner to discuss the topic that they wanted to implement. Using MOB Programming, the owner and team were able to deliver their story that same evening.
Before their day ended, the team and product owner met for an agile retrospective. While not an easy meeting, the team members were highly professional and mature.
One issue that was listed was the amount of time lost during the day. There were several possible reasons for their time management issues but the team felt that the biggest waster was the time that members spent on planning, grooming, and meeting for sprints. Rather than hosting daily sprints, the team decided that it would be more beneficial to only have weekly sprints. They came to this conclusion using this model:
We hypothesize by <implementing this change>
We will <solve this problem>
Which will have <these benefits>
As measured by <this measurement>
Their sentences read:
We hypothesize by <increasing the length of our sprint to 1 week>
We will <not spend so much time in the meeting>
Which will have <an increase in productivity>
As measured <the number of stories delivered in the same amount of time as before, and by our gut feeling>
During the Sprint meeting one week later, the Scrum Master created a learning wall so that the team could provide input on what they felt they learned during the week. In this method, the staff could measure and clearly see if their changes were effective. The team felt happy when they were successful but frustrated and sad when their changes did not work.
There were 2 possible options they could have learned:
- Increasing sprint meetings to one per week, staff would spend less time in daily meetings which would improve productivity.
- Increasing sprints to once per week would have no effect because there were other external factors interfering with the level of productivity.
Either way, the team felt that they had succeeded in their learning objective.
By focusing their session on the learning aspect, the team assessed and discussed what they learned during the week. They could then use their knowledge to initiate improvements and adaptations in their behavior for the next project. In this session, the team felt successful because they learned from their experience.
Learning is a vital part of the Agile Retrospective that is often overlooked. By focusing more energy on the learning part rather than the outcomes, the team will feel more successful as they adapt their behavior and implement changes to improve their performance for future projects. For more information or ideas, visit this List or read Tools for Distributed Agile Retrospectives.
More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.
[trx_infobox style=”regular” closeable=”no” icon=”inherit”]
About the Author
Luis Gonçalves is the co-founder of Evolution4All and founder of ScrumMaster Growth.
He is co-author of Getting Value Out Of Agile Retrospectives which has more than 25,000 copies distributed and discusses the importance of Agile Retrospective.[/trx_infobox]
Software is a Terrible Thing to Waste
By J. LeRoy Ward, PMP, PgMP, PfMP, CSM, GWCPM, SCPM | Executive Vice President – Enterprise Solutions, IIL
Waste. It’s such a, well, dirty word.
But that’s what’s going on in the software industry every day. In fact, software waste, or the amount of software purchased but not used, costs organizations in the U.S. alone roughly $30 billion a year.
According to the Borgen Project, this is enough money to solve world hunger. So, while Mark Andreesen famously remarked “software is eating the world,” in reality the world could eat more based on the amount of money that’s being wasted on software. Funny how things work in life.
Why? Because organizations are buying software that is either not used at all, or is used for a specific period of time, let’s say for a particular project, but then never used again. However, the organization continues to pay the “per seat” license or subscription fee to the vendor because it’s installed and available for use.
For example, when was the last time you used Visio on your laptop?
As an FYI, the titles with the most waste include (percent figures indicate amount of waste):
Attachmate—Extra! Extreme (49%) and Reflection X (52%)
Microsoft—Visio Standard (52%), Project Professional (45%), and Office Professional + (7%)
Adobe—Acrobat Professional (22%) and Photoshop (43%)
Autodesk—AutoCAD LT (58%) and Inventor (61%)
One way to identify this unused software is to implement automated solutions as a complement to other software asset management (SAM) practices. Certainly any large IT organization with thousands of “seat licenses” spread over hundreds of software titles, such as the ones above, might consider making this type of investment.
But that’s addressing the problem after-the-fact, when the “horse is out of the barn,” so to speak. Another way to reduce software waste is to do a much better job of requirements gathering and management before purchasing such licenses or subscriptions, so you know just how many to purchase in the first place.
There are many different requirements gathering techniques and tools that can be used to collect information from large volumes of people as part of a software provisioning project. One just needs to break out of the mold of always collecting requirements in the same way that’s been done for years. One piece of advice is to make sure there is an experienced Business Analyst on your project team to help select the best way to do this. After all, that’s what they’re paid for and they can be very helpful in this regard.
If by doing a better job of requirements gathering, combined with other SAM techniques, we can cut software waste by 50%, we’d save our organizations close to $15 billion! While it would be great if management would put that back into our paychecks (or better yet, feed the world’s hungry) if all that happens is a greater investment in training or creating better products for our customers, then it’ll certainly be worth the effort.
After all, software is a terrible thing to waste!
[trx_infobox style=”regular” closeable=”no” icon=”icon-desktop”]Visit the IIL website to learn more about our Business Analysis courses, and get 10% off when you register with code: BLOG.[/trx_infobox]
J. LeRoy Ward is a highly respected consultant and adviser to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs.
How to Get Your Project Team to Speak Up in Meetings
By J. LeRoy Ward, PMP, PgMP, PfMP, CSM, GWCPM, SCPM
Executive Vice President – Enterprise Solutions, IIL
I’ve never been a “big meeting” kind of guy. While many people find it hard to believe, I’m an introvert (INTJ on the Myers Briggs scale) and I tend to sit there and let the extroverts “think out loud” and the self-promoters hog the conversation. I was once pulled aside by my boss who rightly chastised me for not participating enough.
He told me he not only wanted to hear my opinions, he needed to hear them given my substantial expertise and background in the issues at hand. He was right. After that I tried hard to participate more, but to be honest, it wasn’t easy. Over time and with a lot of practice, I’ve gotten more comfortable in big meetings, but I’d still rather avoid them if I could!
You see, I’m at my best (or at least most comfortable) one-on-one or in very small group meetings. And, I’m not alone.
There are thousands of people just like me, and chances are you have a few on your project team. But like my old boss, you not only want to hear their thoughts and opinions, you need to hear them. That introvert sitting at the end of the conference table, off to the left (which is the best place to “hide” in a meeting) could probably save you from an embarrassing situation with a key stakeholder, or might have the best idea to solve a thorny problem.
So, how do you get that person to speak up?
Writing for Harvard Business Review, Bob Frisch and Cary Greene offer the following suggestions for ferreting out that important information from your team.
Take anonymous polls.
Ask people to write down questions or concerns on index cards, put them into a bowl and read them aloud without using names. Better yet, use a polling app or device to query meeting participants and see their answers in real time.
Heat map the topic.
Put poster-size charts of the components of an idea or plan on the wall. Ask participants to place yellow dots on the charts where they have a question, and red dots where they have a significant concern. Use the dots to guide the conversation.
Break up a big group.
People are more likely to participate in small group discussions. So divide people into teams with specific instructions to discuss any challenges to the proposal at hand. Appoint a representative from each group to summarize their and their colleagues’ thoughts.
Ask them to empathize.
People are often more willing to speak on others’ behalf than their own. So when you solicit opinions with a question like “What objections or concerns might your direct reports have?” it can open the floodgates of reaction. That’s because it allows those in the room to externalize criticism. It’s not what they don’t like. It’s what they think their people won’t like.
I’d like to suggest two more ideas:
Meet with your team members individually.
Sure, it takes more time but you’ll avoid all those weird meeting dynamics inherent in large gatherings.
Use the old school technique of calling on the person who’s not speaking.
While you don’t want to embarrass someone into participating in the discussion, projects are important and soliciting your team members’ thoughtful advice trumps worrying about whether they feel as if they’re being picked on.
And one last piece of advice: the next time someone doesn’t speak up but approaches you later with concerns about what was said or decided in the meeting, remind them that it’s important for them to participate in the group setting. It shifts the burden of action from them to you, and we both know you have better things to do.
[trx_infobox style=”regular” closeable=”no” icon=”icon-desktop”]Learn more about IIL’s Leadership training at www.iil.com. [/trx_infobox]
J. LeRoy Ward is a highly respected consultant and advisor to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs.