\ Kathy Loveless, Author at Strive Consulting, LLC. All Rights Reserved.

The Superpowers of Top Tier Project Managers

Today, it can feel like there is a Project or Program Manager (PM) around every corner. Some have little to no experience, while others are Project Management Professionals (PMP’s) who majored in Project Management and are true subject matter experts. On paper, they can look very similar, but how do you find that one person who will be able to manage implementation of your challenging ‘next big thing’, along with stakeholders, vendors, teams, and competing priorities?

That is where the project management ‘superpowers’, otherwise known as soft skills, come into play. A Project Manager with strong soft skills will have everyone pulling together as one unit in an organization, setting your team up for successful development, growth, and client delivery.

Here’s some of the skills that you should look for and why:

Neutrality

Project Managers with this skill know how to stay in the middle. They don’t play favorites, whether they’re in Information Technology, Project Management Office, or on the business side. Even though they don’t take sides, they should act as a translator, helping all departments understand each other and work together.

Organization

A Project Manager without organization is like a boat without a rudder. Their job is to keep everything accessible and stored, so all team members can access information quickly and efficiently. Thinking logically about file structure, communication, and people management across all levels of stakeholders and team members is paramount. An organized Project Manager makes sure nothing languishes. They keep prompts coming in a timely manner, so tasks are not forgotten or take longer than estimated.

Communication

Communication is a major skill for keeping all members of a team informed at the appropriate level. When people know what is going on, they are less likely to escalate. A good communicator will present their information in a timely manner, especially in the middle of a project where decisions may need to be made quickly. Top tier Project and Program Managers will be familiar with multiple forms of communication and will know when and where to use them.

Transparency

One of the most difficult skills throughout any organization or position is transparency. When something goes wrong, it’s natural to want to hide it. A professional Project Manager will encourage team members to keep the team informed of concerns, so everyone can work together to find a satisfactory solution. If the issue impacts the larger project, stakeholders will need to be informed. Through honest communication, Project Managers can build trust between all parties involved. Trust doesn’t mean stakeholders won’t have questions or want to know details, but consistent transparency will make the conversations easier and more productive.

Conflict Resolution

As anyone who has worked on or with a team knows, there will be conflicts. It is the Project Manager’s responsibility to push for resolution. The Project Manager needs to make sure all voices are heard. For example, they won’t let one individual drive the resolution when a quiet team member may have the perfect solution but may be afraid to talk or lacks confidence in their idea. A Project Manager that keeps their head, while all others have lost theirs, is priceless and necessary.

Anticipation

An experienced Project Manager will anticipate where a project may run into problems and work to minimize those chances of occurrence. Skilled Project Managers can pre-empt issues by utilizing their understanding, experience, and knowledge. Identifying issues and addressing them beforehand will save hours, possibly days, of project time, not to mention your budget.

Proactivity

Along with anticipation, proactivity ensures schedules are kept and team members stay busy. Project Manager leaders don’t wait until someone asks them to schedule a meeting for a necessary discussion – they get it on the calendar. Making surer to look ahead and identify things that can be completed ahead of time or in parallel protects the project schedule and time management of all involved. Proactive Project Managers are always looking for ways to implement efficiency in their day to day.

These ‘superpowers’ are hard to teach skills and are often innate, but top tier Project and Program Managers will be able to use them on your next project. Experienced Project or Program managers are invaluable to any organization and should be sought out often….and you’re in luck! Not only does Strive Consulting have a host of qualified Project and Program Managers ready and willing to partner with your organization, we can also help you find your own valuable resource.

Subscribe

Categories: blog, Management Consulting, Thought Leadership

Messing with the Scrum Recipe

Scrum has been around since the mid-eighties, so why is it that some companies make it work so beautifully, while others end up in such chaos that they run back to old methods? Maybe the companies that flounder or fail, do so because they stray too far from the “Scrum Recipe.”

Companies prefer to put their fingerprint on their version of scrum not unsimilar to today’s health conscious substituting all kinds of things for ingredients in Grandma’s tried and true recipes. They substitute butter with apple sauce; cream cheese with cottage cheese; and sour cream with yogurt. Although the substitutions may make sense, sometimes they don’t work out and you’re left with a plate of cookies that should probably be thrown out. The same can be said for scrum substitutions.

Much like cookies that sit uneaten on the plate, in many cases too many wrong substitutions made to the scrum recipe impacts success. Let’s take a look at some substitutions that may be impacting your successful scrum environment.

IT Product Owners for Business Product Owners

Some companies think IT Product Owners and Business Product Owners are the same thing. That is not true. The whole point of the Business Product Owner is to bring customer facing insight into the development process. The two are measured by different things. The business owner is driven by growing the reach of the product in the market where IT management is measured by things like up-times, responsiveness, speed, and stability. If the product has users and a business owner in charge of strategy and direction of that product, that scrum Product Owner should not reside in technology. The equivalent of this substitution in the cooking world is tantamount to substituting a professional chef with a short-order cook. Are they familiar with food? Yes. Can a short-order cook do with food what a chef can? Not usually.

Make sure Product Owners are part of the group that sets direction for the product. In the case of multiple business product owners driving the direction of the product, a single product owner can be identified in technology to manage the multiple requests and lead the other business owners in the prioritization effort, but the direction should still be driven from a business standpoint. What does it help to have a product that is fast at doing something the users didn’t care about?

Allowing Changes During a Sprint

In the rush to get changes out the door, many companies ignore the directions in the scrum recipe that state no changes after sprint planning. For some reason they believe they can do it without repercussions when others before them have failed. This practice is equivalent to having started making chocolate chip cookies only to switch to brownies. You may not have the resources you need, the work done may have to be thrown out, and worst of all, the team has been impacted negatively.

There’s a rhythm to a sprint as well as a trust that the agreement made in planning will be kept and everyone is working in the same direction. Making changes to a sprint, especially when it becomes habitual, damages the trust and impacts the sprint rhythm never allowing the team to succeed to the best of their capability. It also means you might never get those chocolate chip cookies.

Making Scrum Teams Too Large

Scrum team size recommendations vary, with most somewhere between 7-9 team members. Some companies decide, usually based on previous team size or reporting structure, to have large teams. Initially this seems an innocent substitution but over time the issues become obvious. Stand-ups can’t be completed in 15 minutes; collaboration across the entire team is difficult; quieter team members lose their voice along with many other complications.  Seven to nine is recommended to allow the team to have enough expertise but still be nimble. This is equivalent to the age-old reference to too many cooks in the kitchen. If too many people are trying to do something, even the smallest task becomes more complicated.

Stick to the Basics First

When trying a recipe for the first time it is best to stick to the recipe. The same goes for scrum. Sticking to the recipe doesn’t mean you can’t change it in the future and make it your own, but it’s best to get the recipe right before you start making changes. With scrum, start with the scrum tenets. As your teams learn scrum and are empowered to offer improvements through channels like the retrospectives, the substitutions made will make positive impact. Before too long the scrum environment will be running smoothly and will have nuances incorporated that work for the company without impacting effectiveness.

Looking for more information? Let’s Talk!  

Here at Strive, we take pride in our Management Consulting practice, where we can assist you in you organizational Scrum, Project Management, or Agile Transformation needs. Our subject matter experts’ team up with you to understand your core business needs, while taking a deeper dive into your company’s growth strategy.

Categories: blog, Management Consulting, Thought Leadership

Do You Know the 5 Stages that can Affect Agile Team High-Performance?

As the Agile Manifesto celebrates its 20th anniversary this year, it is not lost on anyone that the popularity of the Agile methodology has grown exponentially during this tenure. That growth has now led to many companies instituting enterprise-wide Agile frameworks, such as Scrum-of-Scrums and Scaled Agile Framework (SAFe®) to continue improving Agile efforts. These efforts focus heavily on the higher-level view of Agile; however, it is still good to remember the wisdom and importance of the smaller teams and initiatives that create a solid foundation. Remember, “a chain is only as strong as its weakest link.”

Oftentimes, companies become so laser focused on making the ‘big things’ work, they forget that the small things must still be watched. The smallest unit in the Agile world is the team and if there are any issues at the team level, that becomes the weak link and could break the enterprise, or at a minimum, impair it.

Team Formation

Traditionally, teams are formed based on projects. According to the Project Management Institute (PMI) “a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal.” Projects have defined timeframes, scope and resources routine operations do not. Project teams are usually pulled together at the beginning of a project after funding is obtained and disbanded when the scope is completed. Teams look different for every project.

In 1965, Psychologist Bruce Tuckman identified the four stages teams can follow to reach high performance. He named these stages Forming, Storming, Norming, and Performing. Later, he added a fifth entitled Adjourning.

  • Forming: Members are getting to know each other, and guidelines are established. Sometimes referred to as “the honeymoon phase.”
  • Storming: Resources start establishing their voice within the team and begin to question leadership choices and previously identified guidelines. This is a very individual, self-focused stage.
  • Norming: Teams have identified ways to resolve conflict and have established agreed-upon processes and procedures. They have begun working as a team and focusing on the job at hand, rather than themselves.
  • Performing: Team members now work as a unit solving problems on their own and focusing on team goals. Issues are resolved quickly, often causing no delay in progress.
  • Adjourning: Team members are looking back retrospectively to identify better ways to have done things or are looking to the future to understand what is next for them. Minimal focus is on production at this stage.

5 Stages that can Affect Agile Team High Performance?

The Tuckman cycle repeats itself for every new team. Since projects have a beginning and an end, a team may never reach Norming, much less Performing, depending on the length of projects or number of team challenges. So, if this is the ‘weak link’ in an organization… what can be done?

Get to Performing

One of the most popular and often recommended solutions is dividing teams into Product Teams rather than Project Teams. Team member are assigned based on skills needed for a product, rather than a specific project. The team is then budgeted on an annual basis and prioritizes features and functions for the product. The team remains together for the entire year or until the product is complete. Since the teams remain together, they move through the team phases within the first few months and then reach Performing to produce features and functions at the fastest pace possible. Quality improvement will also be a result of the improved performance.

The second team set-up is still around projects, but the team remains the same. This structure is often used on large products that have multiple projects therefore needing multiple teams. Teams are formed with resources that will be needed for the product. The projects are prioritized by a central representative or committee. When a team completes a project, they are assigned the next prioritized project. Since the teams remain the same, they have the chance to reach the Performing stage. Some teams will become so high-performing they are able to complete one project in a Retrospective one afternoon, and then kick-off another project with  iteration planning the next morning.

Continuous Improvement

Companies who are striving for high-performing Agile structures should continue to look at all aspects of their operations to ensure peak performance. As organizations begin to concentrate on implementing broader Agile frameworks, they should remember Agile is about continuous improvement. Teams and other previously implemented standards and processes should always be under review.

Strive Consulting has direct experience in Agile Transformation and working with teams across industries and technology platforms to make sure organizations are operating at the highest level possible. Take a moment to read our previous publication ‘Moving from ‘Project-Based’ to ‘Product Based’ where we discuss benefits such as, quicker business outcomes, improved customer experiences, reduced organizational friction, and increased trust between impacted stakeholders.

Interested in learning more about how Strive can help teams operate at peak performance? Join Strive Consulting and our client JLL on April 29th, 2021 @ 11:00AM CST for our upcoming webinar ‘Accelerating Growth Through the Development of High-Performing Teams’. We’ll walk through the key elements needed to analyze and diagnose core organizational growth issues with tools like:
– Conducting interviews and synthesizing into themes and root causes
– Organizational design
– Process design
– RACI and Responsibility definition
– Governance and KPI measures
– Implementation best practices to roll out change

Categories: blog, Management Consulting, Thought Leadership

Are Your Project Managers Prepared for the Cloud?

The previous year has brought about new changes to many work environments, while accelerating other planned changes such as Cloud deployments. According to the July 2020 Forbes article “Why Enterprises Are Accelerating Cloud Adoption: The swift move to working remotely has meant a spike in the number of companies moving to the Cloud.”, companies like Microsoft and AWS have shown significant increases in their Cloud products in recent months. Consequently, more and more projects will be green-lighted to move systems to the Cloud, which increases the need for Project Managers who understand the unique challenges such projects require. Organizations need to ask themselves…are your Project Managers prepared?

Vendor Management Experience

Cloud projects are inherently different than onsite projects that use local and internal resources. Organizations are now managing systems through remote, third parties, so strong vendor management skills are a must for Project Managers. Instead of resources that are dedicated to the company, Cloud resources serve another master. Project Managers need to ensure the Cloud vendor understands the company’s needs and priorities. Stakeholder desired timelines should be reviewed with the vendor to identify any concerns with any challenges addressed early in the project.

Additionally, the Project Manager needs to identify any processes or restrictions varying vendors may have, such as lead time for equipment delivery or holiday freezes. The Cloud vendor standards will drive most of the processes and need to be clearly understood. For example, if a vendor only does quarterly releases for all clients, then a planned delivery date outside of these standards cannot happen. Flexibility for delivery dates will be more limited in the Cloud, so all parties need to understand expectations.

Deeper Software Understanding

Companies have been installing software onsite for years and have become accustomed to making software adjustments to fit very specific needs. When companies select shared Cloud environments to assist with budget restrictions, this flexibility can be greatly reduced. A Project Manager should ensure restrictions are clearly understood or delivery can be disappointing.

A good example is how sign-on’s are managed. Can single sign-on (SSO) be used? If possible, what exactly does that mean? If a software can maintain data from multiple customers of a company, does a corporate resource have to have multiple logins to access each different customer data set or can they access all via single log-in? If able to access via a single login, does that mean customers could potentially see each other?

Do not assume the answers to the questions. In a previous project, this exact scenario occurred. The Cloud vendor said SSO was possible. Internal resources managed many different clients. When the situation was drilled into, clients were able to see each other via a pop-up menu. The onsite version of the software had the capability to block this view, but the Cloud version did not because a software change would impact all clients of the vendor. The only way to prevent the viewing was for each client to be in another “Cloud instance” that further required a separate login for each client. That meant the internal resource needed a different log-in for each supported client. Does that sound like traditional SSO? No, but from the vendor’s side, it was possible as a pass-off from the company to the vendor, but using the SSO, would have created an insurmountable issue.

Gap Analysis Skills

Many companies choose Cloud offerings to allow for focus on core capabilities. Moving hosting and release management to a vendor can provide significant cost benefits. This often means that companies decide to transition on-site versions of software to the Cloud. The challenge is, even when the software is moving to the Cloud version of itself, there is often a gap. These versions differ for various reasons. One of the most common is they are constructed separately. One version is created for flexibility onsite and based on a single company’s requirements. The other is developed to work with multiple companies in a shared infrastructure. Although the product is the same brand, the software codes are developed separately. These differences are usually discussed at a high-level during sales meetings, but when the project kicks-off, the Project Manager and team need to understand differences at a detailed level. Understanding differences in menus or terminology, as well as infrastructure and outputs.

A good example is how is data handled? When moving programs to the Cloud there is almost always data that must be moved for historic reasons. A Project Manager should not assume it is a one-to-one transfer. It is not unusual for two programs to be developed in totally different teams who may never talk to each other. Knowing that data mapping is critical to the success of any Cloud product, some vendors will provide processes for easy transfer if the data infrastructure is different, but others will place that work on the client. Clarification on these types of organizational pitfalls is crucial before kick-off or before schedule baselining.

The skills above are a good start to identifying stronger Project Management skills needed for Cloud environment projects. Overall, when running Cloud projects, Project Managers need to increase diligence in several areas to ensure quality performance as more and more projects will involve Cloud implementations. Strive prides themselves on not only excellent project management experience, but first-hand knowledge when it comes to Cloud adoption and enablement. With our successful and extensive channel partner relationships, with companies like Microsoft and Snowflake, and our robust in-house Management Consulting and Technology Enablement practice areas, our subject matter experts make navigating the Cloud easier and more efficient.

Categories: blog, Digital, Management Consulting, Technology Enablement, Thought Leadership
/chroot/home/striveco/striveconsulting.com/html/wp-content/themes/starting-point/resources/views/index.blade.php