Category: Web Project Management

We asked experienced project managers to divulge their #1 tip for newcomers to the field. Not surprisingly, these process fanatics shared a plethora of great tips to help newcomers succeed in this ever-changing area of work.

Read through their project management advice below, and see what you can learn as you walk into your first, second, or even tenth PM role.

“I think that all the important tips could be summarized with a metaphor:
You should be like an Orchestra Director for your team, with a detailed project plan as score.”
— Jose Ignacio Bernaldo de Quiros Ochoa

Everyone Agrees — Excellent Communication is the #1 Indicator of Success

Understand the culture

Communication is key, and much of that will be informal, so building your network and understanding culture and dynamics are key.
Thomas J. Dickie, PMP

Be accessible to learn more

Always allow people to come to you. Be accessible and listen to what project team members will ask or comment all the time. The more you know, the better you are able to make decisions. Buy knowledge and sell solutions unless you want to pay for project deviations.
Fábio Issao Watanabe

Communicate to identify changes quickly

I think that success depends on communication and focus on the goal. Good communication with the team identifies deviations in a timely manner. Good communication with customers can quickly identify changes in scope.
Oscar Teran

Keep detailed project notes to share

Follow up on tasks and Communicate, Communicate, Communicate. Keep detailed notes and make sure everyone on the team is aware of what is happening.
Monteau (Montee) Outlaw

Discuss challenges, roadblocks, & risks

Make sure to be transparent within your core and your extended project team, as well towards your managers, owner, sponsor. Communicate roadblocks, challenges, and risks clearly and in advance for everyone to see. Know and accept: no one cares for, or is as committed to your project as much, as you are/must be.
Janos Veres

Listen to opinions from everyone, even if you reject them later

Keep communication channels open for all stakeholders: the team, the sponsor, the customer, the end user, your boss, etc. I am not saying that you let yourself be manipulated by every party, just try to listen before making decisions. Hear every opinion, then make your route.
Mehmet Degirmencioglu

Respect every opinion as if it were your own

Train communication, create empathy with your stakeholders. Respect and value everybody’s opinions, even if you don’t completely agree.
João Rodrigues

Challenge ideas to make them better

You are hired to manage projects; your team is hired to be the technical expertise to deliver that project. Therefore, if they are telling you something, it’s usually a good idea to take in what they’re saying and, in some cases, challenge it. If you’re not technical, ask for clarification on points you genuinely don’t understand. That’s normally enough for technical teams to make them think through their explanations, so they’ll carry out an internal check to ensure their thinking is sound.
Andrew Hudson

Build rapport and trust with clients

Build rapport with the client. Build trust and then never lose it. Under promise and over deliver. Plan and communicate.
Marc Hammoud

Don’t Pretend You Know Everything on Day One

Always ask “that question”

You may not have the experience needed to do things 100% correct the first time, so keep it real and allow people to give you suggestions. My #1 suggestion to newbies is: Always ask “that question”. Finding a balance between asking questions or following up offline is a talent you will learn over time, but for now, don’t be shy. You might harm your own project by not speaking up until it becomes a show stopper near implementation time. Speak up and you will find your team is truly on your side!
John Skowronski, PMI-ACP, PMP

Don’t isolate your team with overconfidence

Do not think you know everything. I’ve seen too many project managers take a hard line and push things through because they think they know best. That breeds resentment in the project team. I’ve seen project managers exert their supposed technical or subject authority on a project, only for that project to ultimately remove those additions at a later and more expensive stage.
Andrew Hudson

Learn from every experience

You don’t have to know everything about everything — it’s ok to ask questions and learn from each experience.
Ann Lynne Dodson

To Be the Best, Hone Your Leadership & Management Skills

Make sure you motivate and lead your team

Soft skills are very important. The people involved make the difference between success and failure. You can have knowledge and methods, but you need skills to motivate and lead.
Maarten Verreck

Manage your people, not just your documentation

Following the PM process and keeping up with all the communication tools like the risk log, issue log, schedule, and deliverables should all take a back seat to leading your team. For years I prided myself in being really good at the documentation side of project management, but it never really mattered that much. The most important skill a project manager must master is Leadership!
Larry Sparkman

Build a bridge for two-way trust

Trust is the biggest thing for me, because if I don’t trust my technical team then I’m inherently suspicious of them and vice versa. Building a relationship of trust, and therefore openness, is crucial if you are to deliver multiple successful projects.
Andrew Hudson

Stay flexible to take on every challenge

Keep your knowledge constantly updated, trying to develop new capabilities and remaining flexible in terms of project management methodologies to use, etc. Things can change very rapidly in this field, and as the leader of your team, flexibility and a listening ear are most important to manage the risks and change.
Nirmal Singh

Delegate wisely and lead by example

Learn what you can delegate. Learn who you can delegate to. Lead by example. Work harder than anyone else. Treat everyone you touch with respect and kindness.
Lori Galster

Train your people to be future leaders

It should always be remembered that delegation is not purely about sharing workload. Also it gives the team member a sense of ownership and liability and allows them to learn… Today’s team member can be tomorrow’s PM.
Andy Nelson, AMBCS, P2 Cert Practitioner

Think outside the box

The key for successful PM is communication, problem-solving, and decision-making. Working smarter and offering solutions. Thinking outside the box and strategically looking at the bigger picture.
Kassim Toorawa

Protect your team

You “Protect” the project team, they do the rest.
Onur Karabulut

And don’t forget to proactively celebrate success!

The most important part: celebrate with your team who made it possible!
Puneet Gulati, MSP, PMP, ITIL v3

Be the Person Who Keeps Work Organized & Meetings Focused

Use templates to stay organized

Try to stay as organized as you can, use templates and other tools provided by PMI (you can find them on PMI’s website).
Bhawna Mundotia, PMP

Document! Document! Document!

Always keep a track record of the work being done.
Pietro Cecere

Step up and capture ideas during meetings

If you are in a meeting that needs focus because people are talking in circles, step up to the white board or large note pad and start scribing their ideas, requirements, comments, issues, etc. — preferably into actionable categories. Do not speak! Just scribe. If they start to focus on what you are writing, then you can ask them if they want to identify owners for each actionable item.
Jerry B. Fisher

Learn What Inspires Your New Team, Then Achieve Success Together

Know the working culture before you introduce change

First understand the work/culture/situation, and then make your moves/changes. PMs always want to do something new and different based on their experiences, which is a good thing, but do it smartly. You can’t just jump in and start making changes to the system without understanding it; every company has their own limitations, constraints, and culture. Make changes in such a way that they get absorbed in the right attitude.
Santosh Maurya

Understand everyone’s motivations

Learn that project management can be as much about politics as handling projects. Remember that not everyone working on the project is actually for the project. Learn the motivations and intentions of not just your team, but also upwards to the stakeholders and business users.
Andy Nelson, AMBCS, P2 Cert Practitioner

Build a culture of sharing and innovation to build a strong team

Foster a culture where everyone’s ideas are heard to allow more innovation to take place. The added bonus is that the project team itself becomes a lot stronger — team members are far more open to suggesting and working through ideas if they know they’ll be heard, rather than thinking they’ll be shouted down all the time.
Andrew Hudson

Know the Limitations of Your Project Team — And Yourself

Don’t forget the human

The methodologies are great if well-used, but they won’t work if you do not remember that you are working with other people. Human responses are not always logical or predictable.
Tiago Prado

Know your team’s strengths

Understand the skill set & mind set of the people that you’re going to handle in your team.
Prabhu M

Leave egos behind

Be aware of strengths and limitations in your team and, more importantly, yourself. There is no room for egos.
Louie Turcotte, Jr

Find what sets you apart

Determine your specialization and go for it. The best thing you can do is to decide what sets you apart and make that shine. Remember you are turning concepts into realities and it takes creativity to get you there. Develop thick skin and never fall in love with your first draft, no matter what it is.
James L Thompson, PMP, CSM, Executive MBA, ITIL

Ask Questions to Understand Current Processes, & Keep Them Simple

Ask follow-up questions

When someone makes a suggestion, I like to follow up with background questions: When and under what circumstances have you implemented that in the past? Why was that approach successful? What made it more efficient, cost effective, etc.? Then I broaden my scope of understanding.
Lori Galster

Don’t make mountains out of molehills

DON’T make a huge mind-numbing deal out of the project. Newbies are generally so eager to implement their knowledge or are so psyched up about being in the shoes of a PM, they generally end up overcomplicating simple things. I have seen “accidental” project managers perform better than those who come to the job armed with the whole pedigree of PM tools, techniques, and strategies. It’s better to keep work simple and streamlined so that attention can be devoted to planning, actual implementation, and overall scope and quality control, instead of waiting for the heavens to open up and rain down!
Trina Moitra

Make progress the priority

Do not always look at things from a process perspective. Governance is important, but when it impedes progress then there is an issue.
Dave Regan

Clarify Everyone’s Roles & Responsibilities on Every Project

Understand your own role first

Clearly understand your role and responsibilities and your delegated authority. This will depend on the type of organization you’re operating under. Also understand your key stakeholders and their level of influence.
Kassim Toorawa

Analyze project heartbeats daily

I suggest accidental managers follow the RACI model and analyze project heartbeats daily.

R- Who is Responsible to do the work 
A- Who is Accountable for final decisions and ultimate ownership 
C- Who is Consulted before a decision or action is taken 
I- Who is Informed that the decision or action has been taken

The RACI model is helpful to define/identify/clarify roles and responsibilities. Once you have those, match them up with processes. It’s especially useful in clarifying roles and responsibilities in cross-functional processes. For example, an organization may have a person who performs the role of project manager, and may also perform the role of test manager.
Hambirrao Patil

Beware of role creep

Watch for ROLE creep, which is similar to scope creep in a project. In role creep, your role as a PM might be under constant pressure — from academics, LinkedIn groups, co-workers, and especially those working above you. This is because there are so many forces at work around a substantial project, especially in a non-projectized organization where there is no discipline to comply with standardized and repeatable project management processes. There will be pressure to be innovative, be creative, and be an agent of change, and you will have managers asking you to list all your accomplishments. Your ultimate role is always to deliver what is in the WBS and project plan, use a designated process for scope change, risk monitoring, and issue management, and maintain good communication.
Michael Ayres MS, PMP, CISSP, CSEP

Make Sure You Have a Full Understanding of the Project Objectives, Assets, & Risks

Know the project inside out

Understand the project — so the planning, objectives, results that the project wants to achieve, and of course know the monitoring plan: what are the indicators, its tools, etc.
Marta Acero

Set the goals first

Establish the goal and objectives (SMART) of your new project. Once this is done well, I would immediately do the PESTEL analysis and build the SWOT analysis. Then, it’s planning, communication, and organization. For your project setup plan, you can also use the What, When, Who, Which, Where, etc. model.
Osvaldo Mirante, PhD

Understand the project needs

Having a clear understanding of both the functional and technical definition/needs of the project upfront, with stakeholder buy-in, is extremely important.
Muqtader MBA

Make sure the project achieves its original goal

Focus on specified project objectives!
Muqtader MBA

Control the project scope

Knowing your exact scope of work very well is the key to controlling the rest.
Mohammad Hamdan, PMPⓇ

Think about what can outside forces could affect your project — positively or negatively

Look for organizational process assets that are available to you. Identify the environmental factors that will influence your projects and how they’ll be delivered.
Thomas J. Dickie, PMP

Make work actionable

Make sure everything is actionable and responsibilities are assigned and transparent.
Henriette Ebbesen Laidlaw

Allow time for multiple iterations

Plan and drive project activities according to strategic guidelines. Allow the project team a few iterations over viable and plausibly valid alternative solutions. Never be afraid to ask the project owner for clarification or adjustment of target, timeline, resources, or scope.
Janos Veres

Don’t forget to manage potential risks

You need to understand the organization’s culture to make a roadmap and deliver projects on time and within budget. You should also keep an eye on risks arising during the course of project implementation, with a risk mitigation plan in place.
Puneet Gulati, MSP, PMP, ITIL v3

Get Buy-In From Stakeholders Early & Manage Their Expectations Along the Way

Identify every stakeholder

Identify all stakeholders and develop terms of references. This will align all roles of different individuals in the project and make it easier to relate with them.
Lesiba Noah Konaite

Sell the project to all necessary parties

Involve as many as possible stakeholders at the beginning of a project to gain broader buy-in.
Andries Venter, Inclusive Project Manager

Hold 1-on-1 project feedback sessions

Before kicking off the project, connect with all the key stakeholders in 1-on-1 sessions to get their input on the project, their goals, their level of support, etc. This will uncover hidden “gotchas” and misalignment that may come up later if you don’t do this.
Tom Treanor

Make stakeholders believe in the goal, not just the budget

Getting stakeholder buy-in on the outcome and benefit of completing the project is more important than stakeholder acceptance of the scope, schedule, and budget. If decision-makers believe in what the project will achieve, they will be more likely to accept changes to the scope and tolerances if you can show that it will lead to a better outcome. If all you’ve sold is a budget and a delivery date, you’re doomed to failure.
Chris Cox

Continually manage expectations as the project goes on

Manage the stakeholders’ expectations within given limits. That would encompass all the necessary requirements such as deliverables, scope, etc.
John Mpungu

Don’t Be Afraid of Failure, Learn From It

Fail fast, recover faster

Failure is an option. Fail fast so you can recover quickly and learn.
Sreekumar Govindan

Turn mistakes into learning opportunities

Don’t be afraid of mistakes — learn from them. They are the building blocks for future success in this challenging and dynamic profession!
Susan Kirkpatrick, PMP, CSSBB

Deliver what the business actually needs

A high percentage of projects fail because they don’t deliver what the business needs. Even when you have that nice 400-page requirements document that was signed off on, it does not mean everyone understands what is being delivered.
Thomas J. Dickie, PMP

Ultimate Success Comes From Careful Management, Not Just Careful Planning

Manage the problem, not just the Gantt chart

Reality drives the schedule, not the other way around. It’s not about wrangling Gantt charts, it’s about wrangling people and problems.
James Radvan

Plan to succeed & persevere

Every day there is a chance that you will have your back to the wall. Plan to succeed. Coordinate your priorities, delegate to those in your team, and make the project work.
Paul Alwood

Keep your eye on the overall objectives

No one on the business side cares about the Gantt chart or status reports or the PM deliverables. What they are looking for is the capabilities to achieve the business objectives your project will deliver.
Thomas J. Dickie, PMP

And Remember: Nothing Beats Hands-On Experience

You can’t fake experience

Experience is the most valued ingredient of the perfect PM brew, and that can either come with the salt and pepper of years or from a very competent mentor. There is no way to fake experience.
Trina Moitra

Expose yourself to real-life situations early on

Gain as much experience in project management as you can. Books, theory, and concepts are all fine, but real-life situations are much tougher. The more you face these situations, the smarter you become. There is no better way to learn project management than to expose yourself to real-life situations.
Mangal Pandya

Rely on your people skills, and push for the success at the end of the project

Don’t give up. A Project Manager position is not a rewarding job every day. You have to work really hard to get things done (especially in a Matrix environment), so you have to rely on your people skills a lot. (Keep those sharp!) In the end, you will persevere, and when the project finishes successfully, you will love that feeling of success.
Bhawna Mundotia, PMP

What Advice Can You Share?

Let’s keep the conversation going here! Share your advice and thoughts in the comments below. Tell us what you’d add to this list, or expand upon a piece of advice that really resonated with you.

*Note: Some of the above responses have been slightly modified for clarity, grammar, and length.

I was talking to a fellow coach the other day and she was venting a bit about one of her teams and their Product Owner.

Bob, she said, I have an outstanding agile team. We’ve been working within our product organization for nearly two years. In that time, we’ve delivered an application upgrade that everyone has viewed as simply fantastic. Now we’re onto a building a critical piece of new system functionality for them—so we’ve earned everyone’s confidence in our abilities.

We work hard, we work well together, we deliver high-quality working code, and we have fun doing it.

Ok, I asked. That sounds like a fantastic situation. To be honest, I’m a bit jealous.

Well, she said, don’t be. I’m incredibly frustrated with our Product Owner. He:

• always seems to be ill-prepared with stories;
• hardly ever emphasizes or attends Backlog Refinement meetings;
• brings new or under prepared stories directly to Sprint Planning;
• in general is always undecided and under prepared.

We’ve gotten into the habit of being able to work around him and still deliver sufficient customer value at each sprint review…but it’s incredibly challenging. The team has to “bend over backwards” to help develop a view to our backlog.

And he constantly changes his mind, which is the cherry on top – increasing our rework and driving the entire team crazy.

Wow. I guess everything isn’t so great. Then I asked, have you made him aware of the behavior and your (and the teams’) concerns?

Of course, she said. This comes up in virtually every retrospective. He listens, agrees, and then promises to improve. There might be a slight change for a sprint or two, but he always falls back into the same old patterns.

I’ve even tried to escalate it (carefully) to his supervisor. And even she agrees that it’s a problem, but again, nothing seems to change.

I’m at a loss. What do you think I should do?

Taking A Step Back

On the surface, this is sort of an intractable situation. It reminds me that every team, agile teams included, is only as good as their “weakest link”. Sure, teams can collaborate and work around internal challenges such as this. And in some cases that’s the right thing to do. But when the behavior is affecting the entire team’s morale and performance, and when there is no consistent improvement; then I say something needs to be done.

What do you think? And what are the options here?

1. It seems clear to me that the Product Owner’s manager is dropping the ball. There is a performance issue and (apparently) they’re ignoring it. One obvious and immediate action would be for his manager to begin taking it seriously and start actively coaching the PO, with a possible performance improvement plan as an outcome.
2. Could the team “vote the Product Owner” off the island (team)? I’ve seen this happen in extreme cases with team members. It’s a very messy situation and somewhat of a last resort. However, if the team really is being negatively affected, then it might be the most congruent thing to do.
3. Under the banner of “good team play”, should they just persevere along and keep dealing with it? That’s what this team has been doing. Sure, they’re talking about it. But it’s been happening for nearly TWO YEARS. What makes anyone think it will improve without a major intervention?

Overreact Or Underreact

I normally see two reactions to similar situations in my agile coaching travels. Either the team grows impatient too quickly and overreacts to remove someone from the team, many times without having a conversation with the person. It’s just easier for them to complain behind their back and then look to eject them.

Or

Like the team in this example, tolerate the underperforming behavior in perpetuity, working around it within the team. Sure, they bring it up occasionally, but the team essentially accepts it.

Is There Somewhere In “The Middle”?

I sure hope so!

You might be asking yourself, what counsel did I provide to my coaching colleague? Well, I’ll share it with you. But I’m still thinking about the situation and whether my advice was sound.

I told her that the team was “working around” an issue and that they weren’t transparent enough with the effects of the under performance. You see, they were working overtime to cover for the Product Owner and from a results perspective; the team was perceived to be high performing.

I basically said to stop doing that.

My advice was to allow the Product Owner to fail more often and to make those failures more transparent.

For example, the Product Owner was essentially bringing empty stories to the team for execution. The team would then meet with stakeholders and analysts across the organization to fill in the blanks. This would take tremendous time that wasn’t theirs to offer. In the end, they got very good at writing stories FOR the Product Owner.

I told her to stop that, to put in place Readiness Criteria for stories that would enter the teams’ sprints and to not accept “under-cooked” stories. If the Product Backlog became empty as a result of this, then so be it. Raise that as an impediment and wait until the Product Owner did their job and worked with the team to deliver a proper backlog.

I was careful not imply that the team sabotage or not help the Product Owner as a healthy team would. But I was firm in that they needed to stop doing the PO’s job for them AND allow the dysfunction, under performance and honest results to become transparent to all.

I suggested that IF they did this well, then the organization would reach out to the entire team to discover “what was wrong” and to help them “fix it”.

Wrapping Up

Now at this point, we broke the conversation off and went on our way. But I could tell that my colleague was very uncomfortable with my advice. To be honest, so was I.

But I keep thinking that it was a congruent suggestion for handling a “weak link” that is affecting team health AND not improving. That if teams have the option of helping / masking the problem vs. making it transparent, they might want to reflect whether their masking it IS part of the problem.

That’s what I intended here, but I do agree that it’s a fine line to walk. My biggest fear is that teams read this and start throwing struggling team members under the bus. That’s certainly not my intention.

I wonder what you think of my story and my advice? And if you’ve had a similar situation, what have you done?

Most project managers think they ought have total control of  their projects. They feel as though they have some sort of universal responsibility for the team, the client and the process. On some level, they do! But when it comes down to it, the responsibility is on a very high level. On the ground level, there are so many things that a PM cannot control. After all, we manage projects, we don’t control them. Combined teams control projects, and every individual of the team contributes to its prosperity.

You want control, don’t you?

As a PM, maybe your desire to control comes from a good place, because you think that if you can keep an eye on everything, all will go well. You want to be at the center of the project and know what’s happening at all times so you can jump in and solve issues for your team. You want to save them the time so they can focus on what’s important to their roles–designing or coding. That’s completely fair. Asking to be involved in all project decisions is not control: it’s setting expectations for good project communications. That’s not control; that’s good project management.

Your approach can make your simple desire to be involved feel like a ploy for control. So think about how you’re asking for that involvement–make sure that it’s known that you’re asking to help. The way you communicate with your team can truly make a difference between how you–and the role of project manager–is perceived on a team. But remember: actions speak louder than words! If you’re saying you’ll help, then help. Or, know when to recruit help, or just take a step back. As a PM it’s sometimes difficult to distinguish what you should do, what you can do, and what you shouldn’t do on a project. Just because you can do something, it doesn’t mean you should!

For instance, if a design comes through that I’m not fond of, I can offer my opinion. But I know I shouldn’t, because in most cases, the design aesthetic has absolutely nothing to do with my personal opinion. If I don’t love it, I’ll keep my mouth shut. At the same time, if I am reviewing that design and see something that will not make the clients happy (like a typo, or an “unlawful” treatment of a logo based on brand guidelines), I can say something about it and I should. So I will, because it will better the project.

Giving up the feeling of control will make you better.

Part of being a better project manager is knowing when to contribute to ideas and when to jump in and solve a problem. Owning all things PM-related is a good start–you know you can control tangible things like project plans and budgets. Contributing to ideas and providing an opinion on the project make you a part of a creative team. Conversely, asking for opinions on things like the process or plan will help you. If you wrangle for control or try to dictate a process or plan, you’ll immediately lose respect.  Again, the collective team is responsible for a project’s success.

Personally, I prefer to craft a project approach and present it to the team as a starting point. From there, we’ll work together to hone it and make it “ours”. I’ll own the creation of the plan, but take comfort in knowing that my team is behind the process. If they weren’t, I would not be comfortable. I think the same goes for design–if the entire team is on board, we’re stronger for it.

Now that you know I’m not a control freak, tell me about your thoughts on project ownership? Is your team invested in owning the project together and share the burden of the project deliverables, or are you a lone ranger PM? What do you own, and why?