Skip to main content

Tag: Agile

Shu-Ha-Ri and Servant Leadership

In today’s rapidly evolving IT landscape, leadership styles play a pivotal role in shaping the culture and success of companies. With unique challenges and demands, it is crucial for leaders to adopt effective approaches that resonate with the modern workforce. Among many leadership styles, there are two prominent styles within IT companies – servant leadership and dictator leadership. Each leadership style has different implications for IT project delivery and for the delivery leads and/or project managers.

 

What is Dictator Leadership

Dictator (or dictatorship) leadership, despite its negative connotations, can be effective in specific situations (e.g., where discipline and obedience are absolutely necessary). This style involves a more autocratic approach, with leaders making independent decisions and providing clear directives to the team. IT delivery leads may adopt dictatorship leadership during high-pressure scenarios or when immediate action is required. However, it is crucial to balance this style with open communication channels and involving the team in decision-making whenever possible.

 

What is Servant Leadership

Servant leadership is a people-centered approach that prioritises empowering and serving the needs of the team. IT delivery leads following this style foster collaboration, open communication, and trust-building within the organisation. Creating an inclusive work environment, providing resources and support for team members to excel and offering coaching opportunities are key elements of servant leadership.

 

What is Shu-Ha-Ri

Shu-Ha-Ri is a concept that originates from the Japanese martial art Aikido. Aikido master Endo Seishiro explains the concept via the following statement:

“It is known that, when we learn or train in something, we pass through the stages of shu, ha, and ri. These stages are explained as follows. In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebears created. We remain faithful to these forms with no deviation. Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws.”

Shu-Ha-Ri is increasingly popular with companies where Agile methodology influences their project delivery ways of working.

 

Advertisement
[widget id=”custom_html-68″]

 

How Shu-Hai-Ri Complements Servant Leadership

In the “Shu-Ha-Ri” framework, the servant leader guides the team closely at the beginning (Shu), transitions to a more hands-off approach (Ha), and ultimately reaches the stage where team members can make decisions independently while aligning with the organisational vision (Ri).

Example of Servant Leadership with Shu-Ha-Ri: Estimation

 

Shu: A delivery lead provides a pre-defined method of user story estimation, and the newly launched Agile development team follow the method in their first month.

Ha: In the second month, the Agile development team members reach out to the deliver lead to learn other estimation methods. They then decide to use a different estimation method under the guidance of the delivery lead.

Ri: Six months later, Agile development team members review all estimation methods and choose another fit-for-purpose estimation method all by themselves, without involvement of the delivery lead.

 

Playbook of Shu-Ha-Ri

 

Conclusion

Effective leadership in modern IT companies requires an understanding of different leadership styles and the ability to adapt to specific situations. IT delivery leads must navigate the complex challenges of the industry, drive success and inspire their teams to achieve their fullest potential. By adopting a fit-for-purpose leadership style based on the context, IT delivery leads can create a positive and productive work environment that fosters innovation, engagement and continuous growth. The concept of “Shu-Ha-Ri” provides a “test case” for leadership development and allows leaders to evolve alongside their teams.

 

 

Reference:
  1. Wikipedia, “Shu-Ha-Ri”, https://en.wikipedia.org/wiki/Shuhari
  2. Brian Tait, “Traditional Leadership Vs. Servant Leadership”, https://www.forbes.com/sites/forbescoachescouncil/2020/03/11/traditional-leadership-vs-servant-leadership/

Practical PM for Everyone

Project management is a process that, when done well, enables optimal performance. Why wouldn’t everyone want to know how to manage projects?

 

Everyone Has Projects

A project is an effort to create a result in a finite time. According to PMI, “a project is a temporary endeavor undertaken to create a unique product, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.”

Everyone is part of projects. Some projects are long, large, and complex, like a lunar expedition or the implementation of a new system in an organization. Others are moderate and more personal – planning a party, buying a car, moving, painting your house. Others are quite simple, for example getting up and out of the house, packing for a vacation, grocery shopping, doing the dishes, cooking a meal. Even the individual activities of regular operations like answering emails or working to close a sale fit the definition of projects. we can consider them as mini-projects.

 

Therefore, everyone would do well to know the basic principles of project management and adapt them to the size and complexity of the projects at hand.

Professional PMs would add value by promoting wide-spread appreciation and knowledge of project management for all.

 

Agile Adaptability

Applying a complex project management process with forms, protocols, and reports to manage your at home cooking dinner project or a small project that is repeated many times is not skillful.

You might like to be formal and explicit because it makes you feel good but if there are others involved you might drive them crazy and waste lots of time and effort.

 

At the same time, doing any project without a plan, without writing things down (for example a shopping list), with ambiguous or inadequate communication, and without looking back to learn from the experience is equally unskillful. It is likely to lead to extra trips to the store to get missing ingredients, too much or too little food, misunderstandings of who will do what, and when.

Planning, performing, monitoring, controlling, and closing happen in every project, the way we do them varies widely depending on the situation. It was the intention of the earlier founders of the agile approach to point this out and promote the idea that the project team does best to adapt practices to the needs of their project, stakeholders, and setting, while being aware of the need for a degree of structure and discipline.

 

Advertisement
[widget id=”custom_html-68″]

 

The Agile Manifesto:

“We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions     over     processes and tools

Working software                     over     comprehensive documentation

Customer collaboration            over     contract negotiation

Responding to change              over     following a plan.

That is, while there is value in the items on the right, we value the items on the left more.”

http://agilemanifesto.org

 

Communication and Collaboration

To enable an adaptive and agile approach make sure that all stakeholders have a sense of  the basic principles of project management.

The basics are what everyone should know about managing a project, even if they are not managing one. Knowing the process and principles stakeholders can assess how well the project is being managed. They will be able to connect a sense of the project’s health  accomplishment and progress.

 

The basics are:

  1. Plan, to create a clear sense of what is to be accomplished, how, where, by when, by whom, and for how much it will cost. Remember that plans are always subject to change. Planning is not over until the project is over.
  2. Let go into execution, the performance. It’s like dance or a play. You learn the steps and your role and surrender into performing them.
  3. Mindfully monitor and control to assess progress against the plan and to adjust. Make it part of the performance so it doesn’t get in the way.
  4. Close. Take a step back to assess performance. Tie up loose ends. Learn from the experience. Turn over the results.

So simple, if there is understanding, adaptability, effective communication and collaboration.

Without these the project management process becomes a burden. With them the probability of project success goes way up.

 

What gets in the Way?

You’d think that everyone would be eager to apply the basics and to understand, adapt, communicate, and collaborate. But it is not the case.  The principle things that get in the way are:

  • Lack of process thinking – Thinking all that is needed is to put heads down and do the work instead of recognizing that objectives are met by skillfully applying effort to perform a set of definable steps or tasks.
  • Too much process thinking – over formalizing project management, creating unnecessary bureaucracy and overhead.
  • Not recognizing the value – thinking that the effort to manage the project is not worthwhile.
  • Thinking that it is too hard to engage others in the work required – believing that changing stakeholder mindsets about project management is impossible.
  • Personality traits – for example, closed-mindedness, impatience, fear of being criticized and controlled, and over confidence block attempts to implement some degree of planning and control.

 

What to Do About It

Removing the obstacles to implementing the right kind of project management (PM) requires a learning process in which PM champions convince stakeholders that PM is a practical process that adds value by upgrading performance and promoting project success.

Breaking through resistance to PM requires mindset change and changing people’s minds is no easy task.

 

It is not just about getting people to take a PM course, though an appropriate one, with a skilled facilitator, is a good place to start. It is committing to a dialog that addresses resistance to applying PM principles coupled with a commitment to the agility to adapt the principles to fit the projects being performed and the people who manage and perform them.

It takes time and patience with an understanding that much of the resistance is reasonable given experience with dysfunctional PM and rigid project management professionals who don’t adapt the process to the situation at hand.

Are you safe with SAFe?

Agility has proven to be a highly effective tool for global businesses. It has helped organizations adapt to changing business environments and develop capabilities that have helped them overcome several economic challenges. With the recession and inflation fears becoming more relevant, businesses are using Agility as a shield to protect themselves and deliver products faster.

However, scaling Agile across the enterprise comes with multiple challenges.

Although lightweight frameworks such as SAFe have made things easier, it makes one wonder whether it is really foolproof or not. This article will discuss SAFe helps organizations scale Agile principles and how it is a lever for growth.

 

SAFe revolves around value creation

With the increased focus on customer experience, value creation has become a priority for most leaders. But most software development projects are complex with multiple deliverables. SAFe revolves around applying Lean-Agile principles to help teams focus their efforts on delivering products to the right audience at the right time.

It introduces the concept of value stream management that emphasizes the following principles:

  • Build technology portfolios of development value streams: The team must build a technical portfolio by precisely identifying what value is, what value will be delivered from the product, how the value flow will be, take customer feedback into account, and decide how to optimize the product further.
  • Realize value streams with product-focused Agile Release Trains (ARTs): This phase involves the development team applying the ART principles to reduce the delivery time.
  • Form Agile teams that can directly deliver value: At the heart of the product is the team who creates it. That’s why the Agile team must be customer-focused, cross-functional, and have the skills to execute the tasks efficiently.

 

Adopts a culture of communication

A recent study states that 60% of top executives considered digital transformation a critical driver for growth in 2022. And this transition introduces multiple challenges to businesses, big and small. With high stakes, fostering a culture of innovation and collaboration is critical for success.

The SAFe model creates an environment where coordination between multiple teams is possible. It standardizes processes and simplifies hierarchical structures to help teams collaborate closely, avoid risks and delays, and ensure on-time delivery. With cross-functional teams working together, information sharing increases which promote transparency. The heightened transparency enables teams to understand the scope of work and the product vision, which increases the work delivered and overall productivity.

 

It helps you evaluate your current approach and enhance your capabilities

Every software development process requires improvement. But implementing changes or even changing the current organizational approach can be overwhelming. SAFe encourages teams to reorganize their development processes and consider practical aspects.

Here is how:

Traditionally, all software developers agree on a single design, create a solution, and then modify it. However, this did not give them much time. SAFe introduced a better approach: The set-based design. Here developers consider multiple design options, consider the economic and technical tradeoffs, eliminate the weaker options, and ultimately agree on the final design. This approach finds variability and produces better outcomes.

Another thing the framework introduces us to is the concept of continuous integration, whereby all teams’ work is merged in a central repository, and automated tests are run. It helps developers recognize bugs, improve software quality, and release updates faster.

 

SAFe vs other Agile methodologies

Agile frameworks have been around for decades. While each has its benefits, it is critical to understand how SAFe is different and what greater purpose it serves. Let’s do a quick comparison.

 

SAFe and Scrum

Although both frameworks are popular and may seem similar, they are different. Scrum is an Agile framework where cross-functional teams work on complex problems and deliver product updates in smaller timeframes by breaking large projects into small increment cycles known as sprints. The stakeholders review the output, receive customer feedback, and incorporate changes. However, the thing is that Scrum works for smaller projects and is not suitable at an enterprise level.

And this is where SAFe comes in.

SAFe defines an approach for Scrum to make it work for large projects and ensure that multiple cross-functional teams can work together harmoniously to reduce time-to-market. It influences the entire organization and not just one project.

 

Advertisement
[widget id=”custom_html-68″]

 

SAFe and DevOps

SAFe and DevOps are mature frameworks that are often linked together. And for a good reason.

DevOps framework combines the development and operation teams to achieve faster software delivery. It includes implementing a set of technical principles and tools. It helps break down organizational silos and promotes the continuous delivery pipeline.

As the primary goal of SAFe is to enable organizations to deliver customer value, it helps implement DevOps principles at scale. It encourages organizations to follow the CAMLR approach for incorporating DevOps in SAFe. The recent Leading SAFe 5.1 update also talks about this, discussing in-depth how it will be possible to achieve continuous integration, deployment, and release on demand.

 

Looking at the bigger picture: Is SAFe really efficient?

After discussing at length the basic principles of SAFe and how it helps organizations implement other Agile frameworks like Scrum and DevOps, it is safe to say that SAFe is indeed efficient.

Over time, the framework has evolved, and the recent additions successfully address the current business challenges. With economic shakedowns happening across industries, businesses must change their model and become resilient. SAFe has been instrumental in increasing resiliency, and almost every mid-sized organization has put it into practice.

However, skill shortage remains a challenge.

 

With SAFe, Scrum, and DevOps gaining traction, companies need skilled talent to address the implementation challenges and ensure all the principles are followed religiously. Thankfully, SAFe, Scrum, and DevOps certifications can fulfill this gap.

They equip attendees with the knowledge and skills to implement these principles at an organizational level and explore lucrative career opportunities. The recent November job report shows promising results, indicating that payrolls will rise. But the business outlook shows signs of recession. So it is best to prepare yourself for shakedowns.

Integrating User Stories in Project Planning & Deliverable Development

An important part of managing any project is being able to break the project down into its component parts.  A good project manager and project team need to know and fully understand what a project is intended to do in order to plan and develop the details of the project deliverables.

Project deliverables, according to the PMBOK Guide, are, “Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project.”  (Project Management Institute, 2021).  Simply put, deliverables are what a project creates or produces – the output of a project.  Those deliverables can be tangible, such as physical objects like products, or intangible, such as events or processes.  They define what a project should make or do.  When deliverables are correctly defined, each deliverable should come in two pieces.  One piece is the deliverable itself and another piece is the associated success criteria for that deliverable.  Success criteria can be broadly explained as the criteria used to measure project success (Castro et al., 2019).  Success criteria come in a broad range of formats, with elements and standards able to be applied to different projects as appropriate.  If a project deliverable is successfully completed, success criteria spell out in detail what that success should look like.

There are a number of different practices for addressing this part of project planning.  From informal discussion and consideration to structured, formal brainstorming sessions.  User Stories are one tool that every project manager should have in their toolbox for creating and defining project deliverables.

 

User Stories

A user story is a short statement in the everyday language or business language of the end user of a project’s output that captures, summarizes, and articulates what a user does or needs to do with that output.  It states what the user of the project output wants that project output to be able to do or what they want to be able to do with it.  User stories describe the features of a projects output from the point of view of an end user.

User stories have their background in agile practices in software development.  In this context, user stories are written to describe the features to be included in a software or technology project.  Assembled together, the list of user stories makes up the product backlog, or list of features to be built into and included in the project.  Based on order of priority, those features are pulled from the product backlog for inclusion in a sprint cycle.

As agile practices have since expanded well beyond the software and general technology sector and into use in all types of projects, so have user stories.  They have since become a useful feature in describing the output and elements of various types of projects.

User stories are written in a standardized format.  They clearly define the end user in mind (the who), the feature to be described and included (the what), and how the user will use that feature of the product (the why).  The format for user stories is, “As a   (user role)  , I want a   (product feature)  ,  so that I can   (benefit / use description)   .

Who

The “Who” element describes the role of the user.  It asks and answers the question, “who will use the output and receive value from a particular output feature?”.

 

What

The “What” element describes the product feature itself.  This is the deliverable item of the aforementioned output.  In agile teams, this would describe one unit of delivery.  It is a single, individual feature of a projects output.

 

Why

The “Why” clearly describes how the user defined in the “who” part of the story intends to use the feature.  What will they do with the feature and how does it bring value to the output of the project?

Examples of user stories include:

  • As a listener, I need a tuning button, so I can find my favorite radio station.
  • As a theater visitor, I need a ticket, so I can attend the performance.
  • As a convention delegate, I need a schedule of events, so I can plan my day at the convention.

Several slight variations on the format exist, but the general point is always the same – identifying the user, describing the output feature, and detailing its use or function. The elements can be broken down and considered in those three parts.

 

Advertisement
[widget id=”custom_html-68″]

 

Story Cards – simplified approach

Story cards are the tools used to create, arrange, and organize user stories.  Each story card is a user story as a self-contained description of a project feature, with additional accompanying elements included along with it to help further define the details of that feature.  User stories are traditionally written on physical, individual cards in order to establish the details of each user story and to facilitate the reprioritization and rearrangement of the stories for inclusion in the project.  In contemporary practice, story cards can be created and arranged in digital form, using various project management, storyboarding, or digital whiteboard software and applications.  Any format works, as long as it can be viewed, shared, discussed, and changed by the project team members.

Just as user stories themselves have some slight variations in structure depending on the specific methodology followed, so do story cards.  At a basic level, a user story card should include a title, a value statement, basic requirements, size estimation, and acceptance criteria.

 

Title

The title of the story card is exactly what it sounds like.  It is a shortened or abbreviated name of the story.  It should be sufficiently expressive to describe the feature it defines.  Titles help to organize the stories for arrangement and prioritization.

 

Value Statement

The value statement is the heart of the story card, presenting the user story itself in the format previously set out.  It describes the user role, the feature to be included, and the benefit or use of that feature to the end user.

 

Basic Requirements

The basic requirements section is a flexible element of the story card and can be used to further define some of the essentials or expectations of the feature or its development.  This can include anything from aspects of functionality to resources or constraints in producing the feature.  The Basic Requirements element can be included or omitted at the discretion of the project manager or as the feature itself necessitates.

 

Size Estimation

In agile methodologies, the size estimation is typically done using an estimation point system.  In other practical usage, a time estimation is useful to include and sufficient to further define the story.  This is done by estimating, in time or work units, how long the feature will take to complete as described.

 

Acceptance Criteria

Acceptance criteria describe the basic benchmark that has to be met in order to consider the story complete.  It is a description of a successfully completed and functional feature.  Acceptance criteria can be written by asking and answering the question, “If this feature is successfully included, what does that success look like?”

 

Application

In agile methodologies such as Scrum, the collection of story cards makes up the Product Backlog, or list of features to be selected for inclusion and built into the project during an iterative sprint cycle.  For more traditional methodologies, user stories and story cards can serve a number of roles.  They can help to describe and define features of a projects output from an important point of view – that of the end user.  In project brainstorming sessions, this approach helps project team members to take on that role in considering features.  Once those features are defined, they can be added to the deliverables list for the project, either as final deliverables or for inclusion in an iterative development cycle.  Finally, they can be used to supplement a traditional Work Breakdown Structure.  In this way, the story cards can create additional WBS tasks and activities for inclusion in the project schedule.

 

Any way they are applied, user stories and story cards are a useful tool for project managers to have in project planning and development.  They provide a structured way to consider project features, activities, and stakeholder groups.

 

 

References

Castro, M., Bahli, B., Farias Filho, J., & Barcaui, A. (2019). A Contemporary Vision of Project Success Criteria. Brazilian Journal of Operations and Production Management, 16(1), 66-77. doi:10.14488/BJOPM.2019.v16.n1.a6
Kissflow Project. (2021, November 23). How to Identify and Manage Project Stakeholders? Kissflow Project. Retrieved May 31, 2022, from https://kissflow.com/project/project-stakeholder-management/
Project Management Institute. (2021, March 21). PMBOK Guide, 7th Edition.
San Cristóbal, J. F. (2018). An analysis of the mainproject organizational structures: Advantages, disadvantages, and factors affecting their selection. Procedia Computer Science, 138, 791-798.

A Project Sponsor Wrecked My Project

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!