Tailoring Your Approach – PMBOK 3.7

“Design the project development approach based on the context of the project, its objectives, stakeholders, governance, and the environment using “just enough” process to achieve the desired outcome while maximizing value, managing cost, and enhancing speed.” PMBOK, pg. 44

The checklist I was looking at had 15 primary tasks, five per phase-gate. Each task could have as many as three forms to be completed, depending on the type and complexity of the project. I was nervous I’d have to fill all of these forms out, which I assumed would take countless hours. But soon the PMO lead pointed out only a handful of these forms were truly required. The rest were needed only if the team, stakeholders, compliance, or management thought they were. Why fill out 20 artifacts when only 5 were really needed? Music to my ears!!

Your processes should be used as a compass to guide the project, not a hammer to beat you with.

Every company has a different level of process rigor and maturity. There are a number of “it depends” in the process conversation. An entrepreneurial company will probably have more flexibility than a large, publicly traded one. Take time to understand the methodology used today as you begin to take on a new project.

During a project kickoff, talk about the processes to be used and ask for the team’s input. Even though you’re leading the project, team members have been involved in other efforts and may have opinions on what works well and what doesn’t. Their input, in turn, creates greater commitment to those processes implemented on the project. Also, make process a topic throughout the project so it’s continually improved. Rigor at one stage may be reduced or eliminated in another.

There are times, however, where processes must be followed and can’t be altered. For example, when it comes to compliance projects that are subject to regulatory audit (i.e., Centers for Medicare & Medicaid Services – CMS), there are specific processes to follow and artifacts to produce. Sometimes team members may ask why a step is being handled the way it is. Understand why those steps must follow the process and explain its importance. Same goes for consultants who utilize a client’s processes to complete projects. Sometimes you have to color within the lines!

When establishing or creating processes, think in terms of Rules vs. Guidelines. When I ran a PMO, a rule I had is every project had to have a charter, risk register and a schedule. The guideline was it could be as detailed or high-level as the project leader thought it should be based on complexity, the team, and stakeholders involved. If you’re a PMO or managing project managers, give your project leaders and teams creative license (guidelines) to work within the established processes.

Something I have found with tailoring an approach comes from the retrospectives and lessons learned. Quite often, if one project is delivering a certain way, others are also. Before you know it, that way becomes the new norm, and an updated process is born! Pay attention and look for your new best practices coming from the teams.

Remember, no matter how good we feel our processes are, they’re not perfect. Tailor based on the context of the project and ask for your team’s input. Processes can have rules, but should also have some guidelines when applicable. And, if multiple project and project managers are making adjustments, then it sounds like a new process has been born!

Processing…
Success! You're on the list.

Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (PMBOK guide) (7th ed.). Project Management Institute.

Leadership Behaviors – PMBOK 3.6

“Demonstrate and adapt leadership behaviors to support individual and team needs.” PMBOK, pg. 40

Leadership is one of the most critical skills a project professional needs for success. In most instances, project managers are assigned to a project and given a team to which they have no formal authority over. Leadership is the differentiator between telling someone what to do, and motivating them to do it.

Leadership needs to be adaptable. I will adjust my approach for an onsite team different than for an offshore. When it comes to offshore, I’ll lead a team from Germany different than New Zealand. Onshore, my interactions with a MN based team is different than a NYC team. Or, how I lead a team of IT developers will be different from that of a construction crew.

When I comes to leadership, there are three elements that I feel are critical, no matter what the makeup or where a team is located. Those leadership skills are Vision, Psychological Safety, and Culture of Recognition.

Vision is the ability to think or plan with imagination and/or wisdom. For the project professional, this means rallying the team around the outcome of the project, the value it will deliver, the users it will impact, and how each person contributes to that goal. This is a skill that takes time to develop. I learned through trial and error, and watching people share their vision of the future (check out a Steve Jobs presentation on YouTube…good stuff!).

Business Vision - More Floods | Lenexa Ks | Water Damage Restoration  Marketing

Psychological safety is knowing you won’t be humiliated or punished for speaking up with ideas, questions, concerns, or admitting mistakes. It’s a shared belief within a team that others will not embarrass, reject, or punish you for speaking up. Creating that environment, in my opinion, is the responsibility of the project manager. Ask for input and thank team members when they give it. Admit your mistakes and ask for help. Create an environment where it’s OK to communicate openly.

Building a Culture of Psychological Safety | HR Exchange Network

Creating a Culture of Recognition requires the project leader to behave unselfishly and give credit to where credit is due; the team. My team once busted their asses to get an urgent project done. It was required for regulatory certification and the project landed on our desks 3 weeks before it was due. Through hard work and long hours, it got done.

6 Reasons to Implement a Rewards and Recognition Program for Your Employees

Imagine our complete anger and frustration when our director got up at the company meeting and said “I worked hard to meet the regulatory requirements.” “I submitted this and had it approved.” This person didn’t do shit! I’m not sure if they even knew about the project until it was done. They took the glory and didn’t recognize those who did the work. Give credit to your team. They deserve it!

Leadership. It’s a big deal! Great leaders are able to motivate their teams, especially when they don’t report to them. Three elements of great leaders are having and communicating a project’s vision, developing a psychologically safe environment, and creating a culture of recognition. Now go out there and lead!!

Processing…
Success! You're on the list.

Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (PMBOK guide) (7th ed.). Project Management Institute.

Be a Holistic, Systems Thinker – PMBOK 3.5

“Recognize, evaluate, and respond to the dynamic circumstances within and surrounding the project in a holistic way to positively affect project performance.” PMBOK, pg. 37

I don’t know how many times the word “system” is used in section 3.5, but it’s a LOT! Projects, though done to deliver specific scope and benefits, usually interact with other areas and systems/projects within an organization. You can’t view a project in isolation. This tunnel vision can lead to missing other important elements. That’s why it’s also important to know how this fits into organizational strategy so you understand the bigger picture (3.4 talks about this).

For example, I was recently leading a reporting effort. We were ready to start extracting data. Then, someone mentioned one of our source systems was going to change because of a separate infrastructure project. After asking questions and taking a larger view of the landscape, we uncovered that our data mapping would be invalid within a couple months. Because of this interaction, we were able to pivot and avoid costly rework and possible reporting issues down the road.

I used to spend a lot of time in airports pre-COVID, and something you heard and read frequently was TSA’s “If you see something, say something” message. As project leaders, we need to heed that advice and ask our teams to do so as well. Because our project teams come from other functional areas, they can be privy to information you’re not. Advocate that if they see or hear something that might impact the project, they should say something to you. Potential interactions with other systems can be identified early and mitigated. I’ve had more than a few instances where a team member heard something, brought it to my attention, and then asked a lot of questions to gauge impacts.

See something, say something encouraged | Article | The United States Army

PMBOK mentions having “empathy with business areas” as a skill that supports a systems view. I would expand that to having solid relationships and trust built at multiple levels. If someone, either a project team member or other stakeholder, hears of a possible issue outside of the project that could have an impact, they need to feel comfortable coming to you and bringing it up. If you get upset at the slightest potential change, people will be uncomfortable talking about it.

Having a systems view requires not only thinking tactically about your project, but also having a big picture view of all the interactions taking place around you. Knowing a change in something can (and usually will) have an impact somewhere else can uncover potential risks before they become costly issues. Build relationships that allow for potential impacts to be brought up and mitigated quickly. And remember, if you see something, say (or at least ask) something!

Processing…
Success! You're on the list.

Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (PMBOK guide) (7th ed.). Project Management Institute.

Focus on Delivering Value – PMBOK 3.4

“Continually evaluate and adjust project alignment to business objectives and intended benefits and value.” PMBOK pg. 34

This is my favorite principle out of the 12. When I first started my career, the focus was on scope. I would be handed a project and told to get it done. GO! Scope is still important, but the value and outcomes a project delivers are more important.

How to Use Lifetime Value to Create a Facebook Audience That Actually  Converts

Let’s first differentiate scope and outcome. Years ago I managed a project to deliver an internal application to assist with shipping of products. We were given the scope, requirements, and timeline. We delivered on all three and guess what? NO ONE USED IT!! One person tried the application out, said it sucked, and went back to the manual way of shipping. We delivered scope, but did not deliver value with our outcomes (the project was later deemed a failure, but with it came the valuable lesson of organizational change management (OCM)).

Projects are initiated to support a bigger organizational goal. Not all projects have a business case justifying their existence, but somewhere it should be highlighted which business strategy it aligns to (I’ve started including this in the charter). If it doesn’t align to a business strategy, it’s probably a “pet” project that shouldn’t be moving forward. Also, strategies, and the projects that support them, can pivot at any time. Changes in the market, customer preferences, competitive landscape, and COVID are just a few that could cause a pivot to happen.

Pivoting

When it comes to strategic alignment, release your inner 5 year old. Continually ask WHY and HOW? WHY are we doing this project? HOW will it help meet organizational goals? WHY does this internal group or external customer want what we’re delivering? HOW will it benefit them? Continually ask questions until you feel comfortable with the information. You’re the one who has to explain to the project team and stakeholders WHY this project is important and being done. Understanding the business need also helps in decision making throughout the project.

Value can be subjective based on the person or group you’re working with. I appreciate PMBOK pointing this out. Some may say 100% of requirements need to be met to be valuable. In incremental delivery, requirements may be 70% realized but at that point, needed functionality is delivered. A governance decision may be made to stop the project now. Value would come from the product being delivered for intended use and saving money. Gold Star!

There are times when value could be realized not only from the outcome, but also the journey. Recently I was working on a compliance reporting effort where the client was implementing the reports using a new architecture approach. Throughout the project, we worked through various setup and configuration tasks that allowed the team to do their work. It was a bit clunky here and there, but the client built processes during our project that will lead to other successful initiatives in the future. They gleaned a lot of value from our project, and for that they were appreciative!

Projects are far more than just delivering scope. To be truly effective, project professionals must deliver outcomes that add organizational value. Be sure to ask WHY this project is important and HOW it aligns with strategy. Add incremental value if possible and pivot when you have to. Scope is nice, but value is better!

Processing…
Success! You're on the list.

Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (PMBOK guide) (7th ed.). Project Management Institute.

Effective Stakeholder Engagement – PMBOK 3.3

“Engage stakeholders proactively and to the degree needed to contribute to project success and customer satisfaction.” PMBOK pg. 31

Let me tell you a story about why I hammer on stakeholder engagement when mentoring new PM’s.

It was to be the biggest, most impactful project I’d taken lead at that point in my career. We were embarking on a roughly $4M development project, rewriting a popular software application used by thousands. This was also my first time utilizing an offshore development team. The project was well underway and we were about 50% complete. Things felt like they were going well, until they weren’t.

In a company of 17,000 people, I thought I had taken the time to identify all the relevant stakeholders. However, there was a New Product Development team of 4 people that had been missed. This small 4 person team had the power to terminate my project, which they did within 48 hours of finding out it was in progress. Since we didn’t engage them at the beginning (frankly, no one knew this team even existed!), they said due diligence had not been done on market feasibility and growth. In an instant, I had a $2M sunk cost on my record. Damn, that happened fast!

How To Save Your Story From The Sunk Cost Fallacy

In retrospect, if I would have asked more questions, I would have discovered this team and engaged them. Money, and embarrassment, could have been saved. Thankfully, I didn’t get fired and learned a valuable lesson; continually engage stakeholders and ask if there’s any other groups I should reach out to.

Stakeholders have an impact on almost all areas of the project, including scope definition, requirements, budgeting, providing people and other resources, creating or mitigating risks, quality, and implementation/change management. They can come and go throughout your project or program. You will always have them!

My #1 rule with stakeholder engagement is build solid, evergreen relationships. Have an informal meeting over coffee, lunch or a beer. Get to know them as people! They spend a lot of time working, but they also have lives outside of the office. Find out about that. I have yet to meet a stakeholder I can’t connect with on some level. If your project is large with a lot of stakeholders, meet with the key ones that represent a bigger group. Building fruitful relationships now will pay dividends later.

Your project's success depends on internal stakeholders. Here's how to keep  them happy - Backlog

When it comes to communication with stakeholders, I put communication into one of two categories. The first is “Formal” communication. These are the regular status report emails and recurring updated meetings. Think of formal as an expectation and something on your annual review. The second, and in my opinion more important, is “Informal” communication. These interactions aren’t scheduled and can happen at any time. For example, I have an issue and would like a stakeholder’s input. Or, our project needs a specific person or resource and I want to negotiate for those outside of doing formal requests (which usually take awhile). I think of informal communication as where the most work gets done!

Lastly, I’ve been on many teams where the project team and stakeholders were kept from each other. They never met, talked, or been in the same meetings. I don’t like this approach because it can cause an “us and them” mentality. Instead, I have everyone in meetings when it makes sense. I let them talk and ask questions. Be mindful of potential scope creep in those meetings, but let conversations happen and relationships be built.

Stakeholders. You’ll always have them and if not identified or treated properly, they can make your life difficult! Proactively engage stakeholders and build evergreen relationships that not only grow during this project, but in future projects where you may work with them again.

Processing…
Success! You're on the list.

Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (PMBOK guide) (7th ed.). Project Management Institute.