As you continue to manage projects you will see some patterns that land you in trouble. Sometimes learning through the experience is the only way. Regardless its best to keep some things in mind.
This is the bane of a Project Manager’s existence. If you have people on your team that are not fully dedicated to your project you are adding risk. Any organization that structures projects in this manner is immature. This is why. Research shows that context switching has a cost that is never accounted for on projects. Priorities within a project is hard enough to manage, across projects its worse.
The luxury of everyone working from the same room is something I have never experienced in the 20 years I have managed software. This is a constraint that you will have to live with. Especially with the onslaught of outsourcing and offshoring. Keep in mind that this adds risk to the project. There are ways to mitigate this which we will cover but it can be painful. Every additional timezone your team has adds risk.
If you have a team that has a very strong developer there is a risk. The risk here is that solutions are bulldozed into the project by this one person. It is always important to facilitate discussions to ensure that the team is providing the simplest solution for a problem.
In an acronym-infested industry where new new things are introduced almost every day keep in mind that every new thing on your project adds risk. Some of it is inevitable but ensure that there are clear reasons for this.
The most complex part of a software project is to get two systems to talk to each other. In todays connected world this is inevitable. The most straightforward way to mitigate this is to ensure the integrations are done first and that stories are end-to-end. Take the example of your cart application. Adding a payment method would mean talking to a bank. Regardless of how many times this has been done before and how clear the documentation is, it is guaranteed to run into hiccups. Do it first.
Many people forget to consider that there are times when you are replacing a system. If your cart is replacing an old one there might be data that needs to move over. Plan for this early and try to see if you can avoid doing some of the less critical ones.
More a cultural thing but it has an impact on the project. A new client of ours planned on attending our stand ups. The very first stand up scheduled for 9:30a start on the dot by our team. We waited 30 seconds and then got going. The stand up ended at 9:37a. A few minutes later I got a call from our client asking if the stand up was still on. This set a precedent for the project. Meetings are a waste of time but important as a communication tool. We need to minimize this muda. People need to come on time, attend the ones that are required, push back on wasteful ones. Any project where stand ups or retrospectives or demos are deemed unimportant is a risky project to me.
It is important to get requirements right first up. Of course things change but the further up the cycle mistakes are made the more costly they are. Analyze the requirements. Have multiple people look at it. Get it vetted and then some more. Play it back to the Business and see if you have it right. Try to make things simpler.
Like bad code bad stories are sometimes inevitable. You try to do things fast and then slip up. It is important to involve as many people as possible to ask questions of the stories. It is important to get it reviewed by your QA team.
You will never be a part of a project that has a static backlog. It will grow. By how much is a question that will determine how bad things are. Imagine you started a project with a 1000 points and then it became 2000. All things remaining equal you have doubled your project duration.