Skip to main content

Tag: Communication

PMTimes_Feb8_2023

Best of PMTimes: Change Management in Projects – The Overlooked Methodology

Written by Rory McNamara on . Posted in Articles.

The Scenario

The decision to implement a new technology solution is a significant one and, in many cases, a project that typically an organization is unlikely to undertake often. It is a project that requires a significant investment of money, time, and effort and so, return on investment (ROI) represents an important set of metrics that an organization should keep at the forefront of their minds. In almost all cases, the primary ROI metric is in fact a question – “How many people are now using the new software?”. This basic question should never be overlooked and I recommend asking it at the earliest stage of the project and phrasing that question differently- “How do we ensure everyone embraces our new software?”.

This subtle nuance is so frequently missed or undervalued, which is understandable as so much focus is applied to the traditional method of running technology projects; the priority is delivery and subsequently, user adoption does not get the attention it requires. Like a motor car, you can build the finest, most performant engine but if you only include one seat, only a select few people will choose to drive it.

 

The Culture

First and foremost, it is important to understand that having a perfectly designed and configured technology solution will not alone deliver a truly successful project. In the modern professional world, each of us has a significant level of autonomy in how we work and when using technology; we do not share email addresses or mobile phones and we typically undertake our day-to-day jobs differently from the next person. These examples are obvious when we think about them, so we should look at change through a similar lens; change affects people at an individual level.

The human mind is a complex thing; 1.4kgs of intelligence, hope, love, fear, and everything in between. We celebrate and promote our individuality in life, so we must consider everyone’s uniqueness when delivering a project. When we think back to previous changes we have experienced in our professional lives, almost always the same combination of positive and negative questions and remarks are made. Such examples include:

  • “Great! It’s about time we improved that.”
  • “Not for me. The current solution works just fine.”
  • “The last project was a nightmare.”
  • “Wow! This might actually make my life a lot easier.”

It is natural to respond negatively to change. Even as a Project Manager, in the past I have instinctively reacted with pessimism when I have felt a change was forced upon me! It is this realization that has driven me to adjust and develop project delivery methods to encourage people to embrace change.

 

Advertisement
[widget id=”custom_html-68″]

Delivering Change

We need to view delivering successful change as both a lineal and perpetual process. Embracing change starts at the onset of a project and continues throughout the weeks and months ahead until we reach ‘go-live’ and beyond. The sections below include suggested methods for embracing change and delivering a successful project.

1. Ignite Interest – 0-1 month of the project

It is important to start communicating with the user community as soon as possible. This is a vital step- addressing the common complaints raised by users that they were unaware of and/or not consulted about the new software.

Below are some ways to get you started on communicating and igniting interest:

  • Announce during any regular “Town Hall” style company-wide meetings
  • Send an email to announce and sell the benefits
  • If appropriate, force-out screensaver/ desktop wallpaper announcements
  • Print free-standing banners and place in communal areas of the office
  • If screens exist in communal areas, display messages of the new project
  • Utilize the Intranet

The key to these activities is to build interest, not provide copious amounts of information. View this as a method of igniting some excitement so focus on the key selling points of the product.

 

2. Develop Interest – 1-3 months of the project

It is now time to build upon the initial interest that has been generated in the project. We should now be at a point that everyone in the organization is aware of the incoming software; this initial interest needs to be developed. We must remain mindful that one of the most common complaints following a project’s implementation, is that the end-users have not been consulted or felt involved. If someone feels negatively towards an incoming change, it is often because they feel that change has been forced upon them. Here are some recommended activities you can undertake at this stage of the process:

  • Run demonstration Workshops of the software
  • Establish user groups from each business area and run “interview” sessions to develop an understanding of how they work and how the software will need to be optimized for them
  • Set up a small number of workstations for users to “play” with the software
  • Provide regular project updates – most people don’t want huge amounts of detail; they just want to feel included and updated so share timelines and high-level updates

 

3. Empower Users – 3-4 months of the project

Training users on the new software is not a new concept but it is vital. The training delivery method is of particular importance and tailoring the training to specific departments is something that is highly recommended. When planning the training, ask questions such as “How will this department use the software?” With the knowledge built from the steps in stage 1, you will already have this knowledge so let’s use it to develop tailored training sessions. Training can of course be delivered in many forms:

  • Face to face, classroom sessions
  • Training videos/ eLearning
  • Quick Reference Guides (one-page graphical guides)
  • Remote, web-based training sessions

4. Support Users – Go live

To reach this point of the project, a significant level of investment and effort will have been expressed by all parties involved. Users have been trained, informed, and updated, but now they need to use the software. The risk here is that if there is one small gap in a user’s knowledge, then that can spark negativity that spreads throughout their user experience and transfer to their colleagues rapidly. To counter this, I always strongly recommend floorwalking. As outlined in this document, floorwalking ensures users are supported immediately during the first few days of using the software.

 

5. Into the Future

Change- specifically managing and embracing change, is a perpetual concept. Think of it as sliding down a curly-wurly slide and landing on a roundabout! Each twist in the slide represents the steps required for effective change during the project, followed by the roundabout which is the ongoing process of ensuring the change continues to be embraced and enjoyed. Whilst a new piece of software might not be as enjoyable (or nausea-inducing) as a roundabout, it is important to continue to communicate with your users after they have started using the software. Be sure to give that roundabout a “nudge” every now and then to keep it spinning. These nudges are often best delivered as metrics. The good thing about metrics is that they are typically easy to generate and simple to communicate. Consider options such as:

  • Usage stats – share how many people are using the software and when
  • Tangible benefits – where possible, calculate the direct or indirect cost benefits that have been realized vs the cost of the solution
  • Speak to your user community – remember, most software solutions are to benefit the users so be open to their feedback and share it

Summary

I honestly believe that there is no perfect solution to implementing a successful change. The wonders of humankind and technology mean there are just too many variables to have a concise set of rules to follow, in order to achieve a successful change. The points I have made in this document are simply my thoughts and broad suggestions, not a roadmap for success. If I can leave you with one concise suggestion, it is to always put yourself in the shoes of the end-user; base your approach on one that you would be comfortable being a part of.

PMTimes_Feb1_2023

A Project Sponsor Wrecked My Project

Written by Anju Aggarwal on . Posted in Articles.

Sponsors play an important role throughout the life of a project. They help support, shape, and integrate the project to realize the benefits for the business. But the Sponsors can also hinder the success of a project. They can harm a project by becoming too elusive or too intrusive. In this article, I will share the havoc caused by an intrusive sponsor.

 

An Intrusive sponsor tries to take too much control over the project. It is important to remember that the Sponsor is not the Project Manager and, as such, should not be trying to micromanage the project.

 

Let us first start with the definition of a project sponsor.

A Project Sponsor is a person or group who owns the project and provides resources and support for the project, program, or portfolio to enable its success. Every project has at least one project sponsor. Project sponsors are senior managers or executives who liaise between the project and organizational goals.

One of the critical success factors for any project is the presence and participation of an effective project sponsor. The Project Management Institute reports that the top driver of those projects meeting their original business goals is an actively engaged executive sponsor (PMI, 2018). However, the same project management research also found that one in three failed projects are linked to poorly engaged executive sponsorship.

 

Sponsor’s Primary responsibilities:

– Sponsors help clarify project goals from the organization’s perspective and guide project managers to make consistent tradeoffs across the project’s schedule, scope, and resources.

– Sponsors serve as a point of escalation when decisions or actions are needed to keep the project on track for matters outside the authority of the project manager.

 

BUT…

Not every Sponsor wants to be confined to their primary responsibilities.

Not every Sponsor wants to guide PMs, preferring to micromanage them.

Not every Sponsor respects the PMs boundaries and authority.

 

In some cases, a sponsor’s overzealousness to make a project successful can sabotage the project. A sponsor can create or destroy value for a business. They can act as a hinderance to project success.

Here is my true story between myself (the Project Manager) and the Sponsor. Let’s call him Mr. A.

 

Advertisement
[widget id=”custom_html-68″]

 

A brief background about this project

It was a project in a startup company. I was well supported by the Sponsor, who also happened to be the owner of that company.

Here are the few scenarios which lead to the project’s doom:

 

Micromanaging 

As the project had aggressive timelines, Mr. A suggested hiring freelancers to expedite the work. He recommended a few profiles that he had shortlisted from LinkedIn. I selected one freelancer from that list and started working with him.

What an excellent camaraderie between a Sponsor and a PM. Right?

Wrong!

The supportive Sponsor wanted to give more support. He started micromanaging me. He was asking questions like:

How frequently do you connect with that freelancer? How are you tracking his work?

As the freelancer was doing data entry work, I delegated the supervision of his work to another team member. This way, I could concentrate on more pressing issues in the project.

But Mr. A did not like it. He wanted me to supervise that freelancer directly.

 

Overriding PM’s decisions

We were working hard to achieve the unrealistic timelines. As the due date got closer, I decided to share the actual situation with the customer and ask for more time. I hope that sharing the information about the real efforts to complete the ongoing tasks would help the customers see the massiveness of the work. I would own the misjudgments of estimates done earlier in the project (although those commitments were made by Mr. A.)

But it does not matter as we are one team, Right?

Wrong!

Alas, I did not get to share this information with the customer. Instead, Mr. A had a private conversation with the customer and asked for a one-week extension timeline. In place of the extension, he also committed to doing some extra work.

I was caught unaware when I received this information from the customer on a slack group channel.

 

Expect the impossible

We could not deliver the work we had already committed for this week, on top of the extra work due in another week. I became furious! How could Mr. A have this conversation without first discussing the impact of the scope changes with me? Mr. A crossed a boundry and overstepped my authority on this project.

Many other things unfolded after that and I eventually left the project. Mr. A eagerly stepped into the shoes of  interim Project Manager.

I became an observer on this project and provided my help as and when required.

 

How the wrecked project looked

Firstly, the project could not be delivered even after the time extension that Mr. A got from the customer.

Secondly, he made the entire company work on that project.

And thirdly, the customer was unhappy about this delay and voiced his concern over the slack channel by sending angry messages to the entire team.

We all know that for a project to be successful, the Project Manager and the Sponsor need to work hand in hand. And we also know that this collaboration is often missing in projects.

In many cases, the PM has to spend more time handling Sponsor queries rather than project queries.

 

How should a PM handle an intrusive Sponsor?

Before talking more about this subject, understand that it is a sensitive topic to handle.  As in most cases, the Sponsor also happens to be the PM’s immediate boss.

Hence PMs need to handle it so they do not damage the working relationship with their manager.

 

  1. Train and Educate – Sponsors (specifically, those who are also startup owners) must be educated on what it takes to effectively work with a project team. Sponsors should be explicitly and deliberately taught to deal with projects, project issues, and project people. In addition, they need to learn about change management – the effective tradeoff between cost, duration, and performance.

 

  1. Clarify Expectations – Understanding what the Sponsor expects from a PM. They may have a different understanding of what project managers do and how PMs can help them. For example, some people might think PMs just do all the paperwork and nothing else. Ensure the Sponsor completely understands a PMs roles and responsibilities.

 

  1. Set up the Communication plan – Establish the frequency, granularity, and channels for communication between the PM and the Sponsor to share the project progress or impediments. Communication channels include status meetings, automated reports, dashboards, and impromptu conversations. When sponsors start weighing in on all the minor details, the PM can remind them about the agreements made in the communication plan.

 

Project sponsors are essential to the success of any project. They provide the financial support and resources necessary for a project to exist. They can have a hugely positive impact on the success of a project. While they can be helpful, they can also hinder if not properly managed.

 

The three ways in which we can handle the intrusive Sponsor is:

–             Educate them about Sponsor and PM roles and responsibilities

–             Set the clear expectations

–             Be honest with them to ensure a successful project outcome

 

We can also sum up the above three points in a single sentence – A Sponsor needs to know their boundaries and accept the boundaries of a Project Manager!

PMTimes_Jan24_2023

The Fallacy of SMART Goals

Written by Elizabeth Larson on . Posted in Articles.

I recently read a news story about how to keep our New Year’s resolutions. The article was about the use of simple time management techniques, the center of which was setting SMART goals. SMART is an acronym that’s been around for decades and stands for goals that are Specific, Measurable, Achievable Relevant, and Time-bound. Sometimes other words are used, such as assignable, realistic, timely, and testable.

It sounds good. It sounds useful. But simplifying time management into an acronym reduces the complexity of managing our projects to a seemingly simple formula, one that can prove frustrating. It reminds me of countless bosses and sponsors I’ve had who said, “Can’t you just tell me when the project will be done? Use SMART goals to help you figure it out!” Don’t get me wrong. I think this acronym is useful as a high-level framework. But if our goals too high-level, we run the risk of never achieving them. It’s just not that easy. Let me give you some examples using a project to build a house.

 

Specific. What does it mean to be specific? How are specific goals different from measurable or achievable or time-bound goals? In our house-building example house specifications are specific, as the name implies. There are specs for the exterior and the interior. Specs for landscaping, the roof, the plumbing, electrical and so forth. How specific do they need to be? Specs without detail might be helpful as an overview, but not for the actual construction of the house. We need to drill to down for the specs to be workable.

 

Measurable. To say that the house will be complete in 18 months, for example, is measurable. It’s a good starting point. As the homeowner I can start planning when to put my current house on the market or end my lease, when to get current utilities canceled and the new ones turned on, when to arrange for movers and so forth. But when is done really done? I’ve been told a house was done before the gas was hooked up. I was told a house was done, but movers wouldn’t unload their truck because the floors had been finished too recently. We need to get the detail to make important decisions. And as PMs we need to determine who will decide which measures to use and whether they make sense from a project perspective.

 

Advertisement
[widget id=”custom_html-68″]

 

Achievable. Achievable is another one of the squishy terms in the SMART acronym. It’s one of those words that means different things to different project stakeholders. I suspect I’m not the only PM to be told to “just make it happen.” Or “Where’s your can-do attitude?” I can certainly make almost any project happen, but at what cost? How much risk will the organization/sponsor/end users tolerate? Achieving an end quickly might mean making compromises. Who will make those decisions? What about trust and team dynamics? All these components of achievability need to be considered. And that takes time and lots of discussion.

 

Relevant. I’m not sure I understand what a relevant goal is. There are so many different stakeholders on our projects, some of whom do not find the project or its end product relevant at all. Hopefully it’s relevant to the organization, helping it meet its business objectives. But we all know that’s not always the case. I suspect many of us have worked on someone’s “pet project.” Or have had some stakeholder groups resist implementation. Or have managed projects highly relevant to end users but not to higher levels of management and vice versa. Getting agreement on what is relevant and how the project’s relevancy fits in with all the other projects is no easy task.

 

Time-bound. This usually means attaching a timeframe to the goal. I struggle with the difference between time-bound and all the other goals. I think they are intertwined. As a PM I worked on projects that were relevant only if they could be implemented in enough time to get goods from sourced locations to retail stores and on the shelves in time for the holiday season. Is that time-bound? Or relevant? Or I suspect, a bit of all the components of the acronym.

Which brings me to my original point. SMART goals are useful as a framework. But the key to time management success is going from a high-level overview to subsequently lower and lower levels of detail. We can certainly start with SMART. But we need to drill down to really achieve our goals.

PMTimes_Jan18_2023

Best of PMTimes: 10 Steps to Creating a Project Plan

Written by Elizabeth Larson on . Posted in Articles. 5 Comments on Best of PMTimes: 10 Steps to Creating a Project Plan

Published: 05/17/2012

One of the critical factors for project success is having a well-developed project plan. This article provides a 10-step approach to creating the project plan…

 

not only showing how it provides a roadmap for project managers to follow, but also exploring why it is the project manager’s premier communications and control tool throughout the project.

Step 1: Explain the project plan to key stakeholders and discuss its key components. One of the most misunderstood terms in project management, the project plan is a set of living documents that can be expected to change over the life of the project. Like a roadmap, it provides the direction for the project. And like the traveler, the project manager needs to set the course for the project, which in project management terms means creating the project plan. Just as a driver may encounter road construction or new routes to the final destination, the project manager may need to correct the project course as well.

A common misconception is that the plan equates to the project timeline, which is only one of the many components of the plan. The project plan is the major work product from the entire planning process, so it contains all the planning documents for the project.

Related Article: The Project Plan: How Much Detail is Enough?

 

Advertisement
[widget id=”custom_html-68″]

 

Typically many of the project’s key stakeholders, that is those affected by both the project and the project’s end result, do not fully understand the nature of the project plan. Since one of the most important and difficult aspects of project management is getting commitment and buying, the first step is to explain the planning process and the project plan to all key stakeholders. It is essential for them to understand the importance of this set of documents and to be familiar with its content, since they will be asked to review and approve the documents that pertain to them.

 

Components of the Project Plan Include:

Baselines. Baselines are sometimes called performance measures, because the performance of the entire project is measured against them. They are the project’s three approved starting points and include the scope, schedule, and cost baselines. These provide the ‘stakes in the ground.’ That is, they are used to determine whether or not the project is on track, during the execution of the project.

Baseline management plans. These plans include documentation on how variances to the baselines will be handled throughout the project. Each project baseline will need to be reviewed and managed. A result of this process may include the need to do additional planning, with the possibility that the baseline(s) will change. Project management plans document what the project team will do when variances to the baselines occur, including what process will be followed, who will be notified, how the changes will be funded, etc.

Other work products from the planning process. These include a risk management plan, a quality plan, a procurement plan, a staffing plan, and a communications plan.

 

Step 2: Define roles and responsibilities. Not all key stakeholders will review all documents, so it is necessary to determine who on the project needs to approve which parts of the plan. Some of the key players are:

  • Project sponsor, who owns and funds the entire project. Sponsors need to review and approve all aspects of the plan.
  • Designated business experts, who will define their requirements for the end product. They need to help develop the scope baseline and approve the documents relating to scope. They will be quite interested in the timeline as well.
  • Project manager, who creates, executes, and controls the project plan. Since project managers build the plan, they do not need to approve it.
  • Project team, who build the end product. The team needs to participate in the development of many aspects of the plan, such as identifying risks, quality, and design issues, but the team does not usually approve it.
  • End users, who use the end product. They too, need to participate in the development of the plan, and review the plan, but rarely do they actually need to sign off.
  • Others, such as auditors, quality and risk analysts, procurement specialists, and so on may also participate on the project. They may need to approve the parts that pertain to them, such as the Quality or Procurement plan.

 

Step 3: Hold a kickoff meeting. The kickoff meeting is an effective way to bring stakeholders together to discuss the project. It is an effective way to initiate the planning process. It can be used to start building trust among the team members and ensure that everyone’s idea are taken into account. Kickoff meetings also demonstrate commitment from the sponsor for the project. Here are some of the topics that might be included in a kickoff meeting:

  • Business vision and strategy (from sponsor)
  • Project vision (from sponsor)
  • Roles and responsibilities
  • Team building
  • Team commitments
  • How team makes decisions
  • Ground rules
  • How large the group should be and whether sub-groups are necessary

 

Step 4: Develop a Scope Statement. The Scope Statement is arguably the most important document in the project plan. It’s the foundation for the rest of the project. It describes the project and is used to get common agreement among the stakeholders about the scope. The Scope Statement clearly describes what the outcome of the project will be. It is the basis for getting the buy-in and agreement from the sponsor and other stakeholders and decreases the chances of miscommunication. This document will most likely grow and change with the life of the project. The Scope Statement should include:

  • Business need and business problem
  • Project objectives, stating what will occur within the project to solve the business problem
  • Benefits of completing the project, as well as the project justification
  • Project scope, stated as which deliverables will be included and excluded from the project.
  • Key milestones, the approach, and other components as dictated by the size and nature of the project.

It can be treated like a contract between the project manager and sponsor, one that can only be changed with sponsor approval.

 

Step 5: Develop scope baseline. Once the deliverables are confirmed in the Scope Statement, they need to be developed into a work breakdown structure (WBS), which is a decomposition of all the deliverables in the project. This deliverable WBS forms the scope baseline and has these elements:

  • Identifies all the deliverables produced on the project, and therefore, identifies all the work to be done.
  • Takes large deliverables and breaks them into a hierarchy of smaller deliverables. That is, each deliverable starts at a high level and is broken into subsequently lower and lower levels of detail.
  • The lowest level is called a “work package” and can be numbered to correspond to activities and tasks.

The WBS is often thought of as a task breakdown, but activities and tasks are a separate breakdown, identified in the next step.

 

Step 6: Develop the schedule and cost baselines. Here are the steps involved in developing the schedule and cost baselines.

  1. Identify activities and tasks needed to produce each of the work packages, creating a WBS of tasks.
  2. Identify resources for each task, if known.
  3. Estimate how long it will take to complete each task.
  4. Estimate cost of each task, using an average hourly rate for each resource.
  5. Consider resource constraints, or how much time each resource can realistically devoted to this project.
  6. Determine which tasks are dependent on other tasks, and develop critical path.
  7. Develop schedule, which is a calendarization of all the tasks and estimates. It shows by chosen time period (week, month, quarter, or year) which resource is doing which tasks, how much time they are expected to spend on each task, and when each task is scheduled to begin and end.
  8. Develop the cost baseline, which is a time-phased budget, or cost by time period.

This process is not a one-time effort. Throughout the project you will most likely be adding to repeating some or all of these steps.

 

Step 7: Create baseline management plans. Once the scope, schedule, and cost baselines have been established, you can create the steps the team will take to manage variances to these plans. All these management plans usually include a review and approval process for modifying the baselines. Different approval levels are usually needed for different types of changes. In addition, not all new requests will result in changes to the scope, schedule, or budget, but a process is needed to study all new requests to determine their impact to the project.

 

Step 8: Develop the staffing plan. The staffing plan is a chart that shows the time periods, usually month, quarter, year, that each resource will come onto and leave the project. It is similar to other project management charts, like a Gantt chart, but does not show tasks, estimates, begin and end dates, or the critical path. It shows only the time period and resource and the length of time that resource is expected to remain on the project.

 

Step 9: Analyze project quality and risks.
Project Quality: Project quality consists of ensuring that the end product not only meets the customer specifications, but is one that the sponsor and key business experts actually want to use. The emphasis on project quality is on preventing errors, rather than inspecting the product at the end of the project and then eliminating errors. Project quality also recognizes that quality is a management responsibility and needs to be performed throughout the project.

Creating the Quality Plan involves setting the standards, acceptance criteria, and metrics that will be used throughout the project. The plan, then, becomes the foundation for all the quality reviews and inspections performed during the project and is used throughout project execution.

Project Risks: A risk is an event that may or may not happen, but could have a significant effect on the outcome of a project, if it were to occur. For example, there may be a 50% chance of a significant change in sponsorship in the next few months. Analyzing risks includes making a determination of both the probability that a specific event may occur and if it does, assessing its impact. The quantification of both the probability and impact will lead to determining which are the highest risks that need attention. Risk management includes not just assessing the risk, but developing risk management plans to understand and communicate how the team will respond to the high-risk events.

 

Step 10: Communicate! One important aspect of the project plan is the Communications Plan. This document states such things as:

  • Who on the project wants which reports, how often, in what format, and using what media.
  • How issues will be escalated and when.
  • Where project information will be stored and who can access it.

For complex projects, a formal communications matrix is a tool that can help determine some of the above criteria. It helps document the project team’s agreed-on method for communicating various aspects of the project, such as routine status, problem resolution, decisions, etc.

Once the project plan is complete, it is important not just to communicate the importance of the project plan to the sponsor, but also to communicate its contents once it’s created. This communication should include such things as:

  • Review and approval of the project plan.
  • Process for changing the contents of the plan.
  • Next steps—executing and controlling the project plan and key stakeholder roles/responsibilities in the upcoming phases.

 

Elizabeth and Richard Larson are Co-Principals of Watermark Learning, a project management and business analysis training company. They have over 30 years of industry experience each, and have helped thousands of PM and BA practitioners develop new skills.

They have published numerous articles and papers and have co-written two books together on Requirements Management and CBAP Preparation. Both Rich and Elizabeth are CBAP and PMP certified through IIBA and PMI, and are contributors to the BABOK® Guide, Version 2.0 and the PMBOK® Guide – 4th edition.

PMTimes_Dec21_2022

Best of: The Paradox of Patience, Planning and Expectations

Written by George Pitagorsky on . Posted in Articles. 9 Comments on Best of: The Paradox of Patience, Planning and Expectations

If your goal is optimal performance, cultivate the mindful awareness that enables clarity and responsiveness. Accept and work with paradoxes to embrace both-and thinking.

A well-respected mindfulness meditation master, advised that “A mind which thinks, expects, and plans, blocks off wisdom.” Following this advice would leave most of our projects at sea without a rudder. That is the problem with a great deal of the mindfulness teachings that have become common in the project management and general business communities – over simplification. The wise embrace both-and thinking.

The full quote is:
“Notice every time the mind is eager for
results and remind yourself of the right attitude.
You need to practice patience.
Only when the mind is simple, can wisdom develop.
A mind which thinks, expects, and plans, blocks off wisdom.” Tejaniya

 

Mindfulness

Mindfulness is the ability to objectively observe everything occurring within and externally. It is beneficial, based on many studies and personal experience. Mindfulness techniques – formal and informal meditation methods – increase mindfulness and concentration. Mindfulness enables responsiveness as opposed to reactivity. Concentration brings calm, relieves stress and enables focus in the face of distractions. Together with effort mindfulness and concentration promote wisdom.

But how many project managers will sign up for simple mindedness? How many organizations will hire simple minded project managers who are not eager for results? Not many.

 

The Wisdom of Paradox – Eager and Patient

Yet, there is wisdom in the master’s advice. Like all quotes it is taken out of context. No meaningful statement about the nature of mind and mindfulness is absolutely true. There is paradox – events or ideas that are unlikely to coexist. Paradox is “seemingly absurd or self-contradictory statement or proposition that when investigated or explained may prove to be well founded or true:” Oxford Dictionaries.

Investigating more deeply, we can know that to be aware of the eagerness for results and to have patience is good advice. Over eagerness in projects leads to rushing to complete, by-passing risk management, testing, and other parts of planning and controlling the project. The over eager stakeholder is more likely to make mistakes and set unreasonable expectations. The eager stakeholder is motivated to achieve.

 

Right Attitude – Patience

The “right attitude,” is to be both eager and patient. Patience is a tough one, particularly when faced with high ranking stakeholders who are eager for results. Patience is “the capacity to accept or tolerate delay, trouble, or suffering without getting angry or upset:” Oxford Dictionaries

Patience requires a stepping back to mindfully observe the uncomfortable feelings that get in the way of consciously taking stock of the situation, planning, communicating, and establishing the most effective foundation for performance. Alan Lokos, in his book “Patience:The Art of Peaceful Living” makes the point that patience is not passivity. Patience is taking control of thinking, speech, and action so that what you say and do makes good sense and gets the results that you want. Patience is an ingredient for effective project management and performance.

Practicing patience requires effort. It requires the ability to notice and be able to accept the urge to dismiss the annoying functional manager or team member who is ‘obstructing’ progress. Noticing and accepting are part of the practice of mindfulness. When I teach meditation practices, I often recommend “sitting with an itch,” patiently waiting for the itch to change or disappear on its own rather than scratching it. Try it the next time you have an annoying itch. It builds the patience “muscle.”

 

Advertisement
[widget id=”custom_html-68″]

 

Who Wants a Simple Mind?

Now lets turn our attention to “Only when the mind is simple, can wisdom develop.”

“Everything should be made as simple as possible, but not simpler.” Albert Einstein

To have a simple mind does not mean to be simple minded. A simple mind, in the context of mindful awareness, is a calm mind that sees things objectively, as they are. There is elegance in simplicity. The simple mind can integrate the sophisticated, complex skills and thoughts needed to manage and perform complex tasks in a complex, changing environment. The simple mind is free of the unnecessary noise of biases, confusion, and obsessive thinking.

Bertrand Russell said, “Every man, wherever he goes, is encompassed by a cloud of comforting convictions, which move with him like flies on a summer day.” The simple mind, the mind that is mindfully aware, sits behind it all, open-minded, free of the comforting convictions. It observes objectively. The simple mind is like the eye of the storm – calm and clear while the storm rages. The flies are still there but they no longer get in the way of clear, focused thinking. In fact, mindful awareness promotes greater clarity and focus.

We can have a simple mind and simultaneously achieve objectives by applying our intelligence, skills and knowledge.

 

Planning, Expectations and Wisdom

To say that “A mind which thinks, expects, and plans, blocks off wisdom.” is overly simplistic. It is misleading. It is the kind of thing that can drive people, particularly project managers, away from the practice of mindfulness and the benefits it brings. The meaning is clarified by saying that a mind that is distracted by thinking, that unrealistically expects, and over-plans blocks off wisdom.

Wisdom is seeing things as they are and having wise intention. Wisdom can be blocked by Russell’s “flies.”

In Buddhist thought, things are impermanent, imperfect and the result of a continuous process of causes and effects. Wise intention is to give up the causes of suffering, cultivate good will, do no harm, and to ethically achieve objectives to benefit stakeholders.

Expectations are normal. Planning is necessary if you want to successfully achieve project goals and satisfy stakeholder expectations. However, having irrational, unrealistic expectations leads to disappointment and suffering. Constantly changing the plan moment to moment, gets in the way of being in the moment and performing optimally.

 

The Bottom-line

In the spirit of both-and thinking, we can say that we can both be patient and take skillful action. We can keep the mind simple and apply complex skills and knowledge to complex problems. And we can expect and plan and be in the moment, performing optimally, while allowing wisdom to develop.

Mindful awareness is the foundation for optimal performance. Cultivate it by practicing to focus the mind and open it to the full range of internal and external experience. Practice both-and thinking.

 

Published on: November 18, 2020