6 Things You Need to Know as a Project Manager to be Successful
“Management is a performing art; it is more right-brained in nature and can be learned only through practice.”
Project management has become very popular in the past few years. It’s about managing people effectively. Even for software project management, it isn’t about technology.
Yes, you may require some technical knowledge to manage a project, but extensive experience of programming is not required to be a successful project manager.
You can launch a successful career in project management with adequate knowledge of technology, if you are good at bringing out the best possible performance from your people.
Let me share a few key things I learned in 3 years of managing projects.
1. Be a project leader; not just a manager
Project management is not easy. You are constantly bombarded with issues. A team member falls sick, your team deploys a project with a bug, your client is delaying the payment, someone senior at work is asking you to execute a task that does not seem at all logical to you, or some of your team members are simply becoming a pain.
This all gets down to becoming a leader. With a lot of responsibility and very limited authority, you have to make others ‘want’ to do something which you believe should be done.
Focus on the word want. You can get people to do something by giving them an incentive or reward, but getting them to want to do something is a complete art.
For this, you need to be aggressive from day one. Share your vision with your team and fuel them up by motivating them so that they own your goals and values.
This will make your life fairly easy. As project management is about managing people, you need to make sure your team shares the same vision as you do.
2. You have as much authority as you are willing to assume
Organizations today give little authority to project managers. You need to seek approvals for many of the steps that you tend to take. But what if that person is unreachable?
As my CEO traveled a lot over the past year during my initial days, there were many situations where I needed his approval to move forward. When I wasn’t able to reach him, I would take decisions on my own, and inform him later about what I had done.
This made me believe what I read somewhere years ago:
“Assume the authority when it isn’t given to you.”
The key here is to put yourself in the shoes of those who have authority. Think about how they would analyze and approach a problem. What matters most to them reflects the decision they often make.
3. Projects often fail at the beginning, not at the end
Consider how projects are kicked off. A pre-sale executive wins a project and gets on board a project manager to do the job. The pre-sale executive shares the concept of the client.
The client and the pre-sale executive are confident that the project manager will convert the hazy concept into a complete product that everyone will love.
The project manager calls in a meeting and shares the project idea with his team, who seem very delighted.
They are all nodding heads and the project manager seems convinced that the idea has been bought.
Right after the meeting, team members ask each other if they understood the idea shared in the meeting completely. But, no one did.
Everyone got lost at some point. They thought they’re the only one in the meeting room who aren’t able to capture the complete picture of the project. They chose to ask their coworkers later, not wanting to look like a fool.
“Many people are socialized to remain quite even when they don’t understand.”
When no one is willing to express confusion or disagreement early on, you are beginning a project that is most likely to fail.
Call such projects that are prepared to fail at the beginning as headless chicken project. When you cut off a chicken’s head, the body moves discharging blood for a while until its completely dead.
It’s actually dead when you cut off the head, but it takes time for this message to reach all parts of the body.
4. Change will happen in every project
Projects begin with a half baked idea, where the sponsor does not really know what he really wants the end product to look and function like.
With agile development, we gain more knowledge as sprints progress. But how do you address uncontrollable changes in a project?
By keeping your documentation complete and securing approvals from the project sponsor at many points, such as:
- Scope boundary
- Functionality requirements
- Design and UX: (Use a tool like, such as Invision App, to show your clients the designs and user journey of the product and have things locked.)
- Acceptance Testing
Whenever a client requires a change once the designs have been approved, don’t forget to document the change requests.
It’s up to you whether you want to charge for the additional feature or not. But, sending a change request document ensures that you are taking them seriously. The client would be prepared to expect a pricing at any particular request along the way.
Otherwise, you will face situations where clients would argue on pricing. Let me share what a friend went through:
“We never thought you’re considering them as changes. We took it as an evolving product and never did a discussion about pricing come across on any request we made earlier. What is so different now?”
Your change request document may have the following items:
- Change request version (to keep track of how many requests have been catered)
- Description of change (eg. Allow users to signup via different social platforms)
- Reason of the change (eg. To on board users quickly)
- Impact on cost (eg. No change, or let’s say, $200)
- Impact on the timeline (eg. 5 working days)
- Impact on the planned sprints
- Acceptance by both parties
If you have been sharing the documents, and later a client argues on pricing after requesting an additional feature, you can clearly let them know about the favors that were given. Show them the requests for which you didn’t charge, and justify the effort involved in implementing the requested feature.
5. The flow of information will primarily decide whether your projects live or die
You will be dealing with a lot of things; conflicts, communications, motivation, decision making and so on. Effective communication plays an important role in determining the success of the project.
Many problems occur because various stakeholders are not kept informed. But not all stakeholders need all the information. You need to plan your communications at the beginning of the project.
A friend ran into a problem where his client had requested some changes and asked him to get back with the impact on the timeline. With years of a strong business relationship, he assumed that like every change request in the past, the client would approve this one too, so why not begin on it immediately anyway?
As this discussion had taken place over a video call, and no minutes were documented, a red flag raised after a few weeks.
The developers analyzed the change and began working on it. Weeks later, the client was billed with the request deployed, to which they responded saying,
“We just asked for a timeline in our discussion, and were waiting for you to get back to us. Plus, we didn’t give an approval to begin and you’re now informing us after deployment that you had made changes to the planned sprints to accommodate it. All this has happened without even informing us?”
And that is what can happen if you don’t communicate effectively. Quick notes to take from here:
- Document meeting minutes
- Get signed approval at every step
- Make sure you’re communicating effectively
6. Find a Mentor to work well with senior management
When I joined the company where I currently work at, I was grateful to have the co-founders as my mentors. I got direct feedback and guidance from them which developed my skills and gave me the confidence to lead.
But, working with people senior to you can get troublesome at times, especially when they have a difference in opinion and use their position to influence decisions. Soon you start witnessing politics at work. Take Mike Ross for example, who had a tough time getting along with Louis Litt during his initial days at the workplace.
The best way to counter this is to find a mentor in the senior management from whom you can learn and understand how he approaches his job. Find your Harvey Specter at work.
This will help you analyze how senior executives view things. You can then make decisions from the same point of view and be confident that your mentor would agree with you.
When we talk about project leaders making team members want to do something they believe in, similarly, project managers also need to put themselves in the shoes of the senior management and approach issues accordingly.
This is a continuous learning and improvement process. Over the time, your seniors will guide you at every step as needed, because you are becoming another them.
A project is a problem scheduled for solution. Every project is different and managing them from initiation to closure is not a child’s game.
You need to make sure you have the right people on your team to develop the full-baked version of what the project sponsor had envisioned.
Be a leader, motivate your team, communicate frequently and effectively with all stakeholders, analyze risks, share knowledge and learn from every person in your team.
If you always do what you’ve always done, you’ll always get what you’ve always got.