Common Project Management Problems

When learning a new way of doing things, we should reflect on our past. What have we seen work well before? What have we seen fail? What would we have changed? Why? How would we want to do it differently in hindsight?

These questions are at the heart of agile project management. Every once in a while, we take a few moments to reflect with the team. If working in sprints, this usually happens at the end of each sprint.

This is a time to listen to the team. Similar to receiving feedback in a writing workshop, the proper response from a manager is, “Thank you.” We are managers if we manage the project or otherwise direct the team. Maybe the team needs more detail in the tasks, or maybe someone’s vacation had an impact we hadn’t foreseen. We constantly tweak how we work to improve what we do as a team. We take the feedback, reflect on it, and adjust the rules rather than try to adjust the people.

McConnell categorizes problems as people-related, process-related, product-related, or technology-related.¹S. McConnell. Rapid Development: Taming Wild Software Schedules. Microsoft Press, 1996. Knowing which category a problem fits in helps us understand what adjustments we might need to make. For example, a product design that frustrates people trying to use the product is a product-related problem and needs a product-related solution, such as a different design. Or if a team is consistently not completing the tasks assigned for a sprint, then the solution might be process-related. Perhaps the team should take on fewer tasks each sprint with the consequent impacts on the roadmap.

Here are some common problems that projects encounter. We’ll see how agile project management can guard against them. What are some other problems you’ve seen?

A project is paralyzed by analysis when work can’t proceed until all questions are answered. Analysis is a process of accessing and mitigating risk. Some analysis is necessary, but if the team can’t proceed until the analysis is completed, then that’s a whole team not working on the project. Too much analysis too early in the project is a hallmark of waterfall project management. Rather than find and plan for all the pitfalls the team might encounter, it’s better to be agile: encourage flexibility in the team so that when a problem arises, the team is confident in its ability to solve the problem.

A project becomes a “death march” when it continues without end.²Yourdon. Death March. Software engineering. Prentice Hall Professional Technical Reference, 2004. Each day is doing more work regardless of progress. The project’s not done until it’s done. Every last item. Everything is a priority and needs to get done eventually. We avoid this by knowing our ultimate goal, creating a roadmap, and prioritizing features.

A project threatens to burn out team members with overtime when everything has to get done by a particular deadline. Everything is a priority, and nothing can be dropped. The only way to achieve this is to work overtime week after week. This is also known as “crunch mode,” but crunch mode doesn’t work.³E. Robinson. Why Crunch Mode Doesn’t Work: Six Lessons. International Game Developers Association. 2005. We avoid this by knowing how much we can do in a day, week, etc., and what work is critical.

A project thrashes when its goals shift from day to day. For example, user research might indicate that a feature in progress needs to be designed differently. It could be due to shifting priorities from someone with power outside the project. Any number of reasons can cause priorities to shift.
We can avoid thrashing by defining our work in a sprint and ensuring that any new tasks are noted but delayed until a future work sprint.

A few years ago, I was part of a team developing features for an important partnering customer. We had gone through several rounds of development and feedback, typical of user-centered agile development. We were now at the point of sending some of our user experience researchers to the customer site to watch them using our product. Each afternoon, around 4:30, we would have a conference call to discuss the results of the on-site observations. At the end of the meeting, we realized that we needed a new feature in our software to improve the user experience or risk losing the customer. So, a few of us would hammer out the changes and push them to production by the next morning, ready for a new round of observations. Sometimes, we put a change in, tested it, and realized we shouldn’t have made it.

We weren’t taking the time to analyze the observations and ask what impact the changes might have. We simply observed and executed. Without solid principles to guide our decisions, we ended up thrashing about. Working long hours with no well-defined goal led to burnout and the feeling of being on a “death march.”

But there is hope. You don’t have to replicate my experience. By focusing on the big picture—the goals—and perhaps some milestones to demonstrate that the goals are not trivial, you can deliver the big picture while foregoing some of the polished or non-critical aspects of the project.

Are you experiencing any of the problems discussed above? Are you exploring agile but aren’t sure where to start? Schedule a free consultation, and let’s see what might be possible.

• 1
  S. McConnell. Rapid Development: Taming Wild Software Schedules. Microsoft Press, 1996.
• 2
  Yourdon. Death March. Software engineering. Prentice Hall Professional Technical Reference, 2004.
• 3
  E. Robinson. Why Crunch Mode Doesn’t Work: Six Lessons. International Game Developers Association. 2005.