Project Management: Making the Right Decisions by Diving in

Article initially published on Softvision Insights

The life of a Project Manager in the Agile Transformation Guild at Softvision is focused on two significant directions; one is making sure that the team is delivering quality work on time according to customers’ needs. The other is motivating the team, balancing the activities and pressure, so everyone feels comfortable in their role, for longer-term assignments.

These two directions are very crucial, and losing the balance between them fixes short-term needs. These needs can be the quick delivery of an important module or providing breathing room for the team after a rough milestone. Applying this system for a longer period generates unwanted consequences.

As the team is mostly focused and engaged with day to day tasks, it’s the Project Manager’s role to know the project work in detail, as well as understanding the high-level situation that’s coming from the business side. Many times, if you’re not taking into consideration the business part, decisions, priorities and delivery roadmaps seem to be unreasonable and disconnected from the technical side.

This is where conflicts appear, and the Project Manager’s approach is essential for the positive outcome of the situation.

Finding the gap

In my years of practice, I’ve seen many situations where someone from the engineering team would approach the Project Manager and say, “I don’t know what’s going on right now, but I find this decision really unfortunate! Why was my proposal to improve performance refused? I believe these guys [the customer Stakeholders] are not interested in having a successful product!”.

As it looks, this is clearly a situation where someone is missing something. Starting from the assumption that everyone is following the product’s best interest, the Engineering team from the technical standpoint, while the Stakeholders from a business perspective, it’s the Project Manager’s role to identify the misunderstanding, make his own mind by asking both parties all the needed questions, then use his skills to influence the decision he considers optimal.

Asking all the right questions

When someone from the team is escalating like this, it’s a clear sign of frustration. The first step in understanding and clearing the frustration is to find out where it comes from. The easiest approach is to start asking questions that cover all the spectrum of the situation described above.

In our sample escalation on the performance improvement proposal, the following questions could be used as a starting point, to gain a deeper understanding of the situation:

  • “Are we encountering performance issues right now? If so, how severe are they?”
  • “Are you foreseeing performance issues in the upcoming period? When would this happen, with what impact?”
  • “What would be the effort required to implement your proposal in days/weeks? What would be the benefit to it in numbers?”
  • “If you were to decide the effort spending, why would you refuse such a proposal like the one you made?”
  • “I notice that you are very emotionally affected by this refusal, why is this happening?” This question is meant to make the person aware that the situation should be analyzed from a pragmatic point of view rather than an emotional one. Use it only if you are confident it will not backfire.
  • “What are the business priorities for this milestone? Is the work currently delivered on track?”
  • There are two benefits of this approach:

  • First, the person in charge (in our case the Project Manager) understands all the facts, pros and cons to the approach, emotional connection of the person to the situation and the person’s perspective on things, and
  • Second, the person itself that generated the escalation formulates and rationalizes facts (as facts are the ones that the questions are about, secondary the value judgments and tertiary the emotions attached). Included here are the facts that sustain the opposite view, that sometimes make the person less determined or convinced that their solution is the right way to go.
  • At this moment, we consider we have a clear understanding of the facts and reasons from one person’s perspective; now we need to see the other side of the story. Next thing to do is to schedule a meeting with the Stakeholder that is responsible for the situation and perform the same thought process as the one detailed above.

    Reaching your own conclusion

    Now that all the right questions have been asked and both parties have provided all the necessary information, the image is getting clearer, as well as the facts and consequences that each of the parties did not think of. Engineering could be focused on delivering a great product, and sometimes disregarding the business opportunity of delivering something that’s not great, but it’s there (while the competition does not have it, for example). Business could be focused on onboarding new customers and selling subscriptions while sometimes disregarding that releasing an improperly tested build can backfire in lower user satisfaction. Considering this for a fact, it’s a matter of broadening the perspective on each side, so they understand the implications of a certain decision or approach, wanted or not.

    Reaching your own conclusion – and helping the others understand the situation better while doing that – is the prerequisite for any great decision a manager makes. Don’t be afraid to roll up your sleeves and dig as deep as you need into the facts until you’re convinced you understand everything that’s going on. Once you’ve made your own mind, it’s time to act.

    Implementing and/or influencing the decision

    The performance improvement proposal was initially refused. Conversations took place, and let’s assume the Project Manager’s conclusion was that this was more of a nice to have, rather than a must-have, for the current moment. However, if some action would not be taken, there would be product usability impact in the next three months. So, what to do right now?

    Since action on the product performance is important, but not urgent, the related activities can be included in the backlog, right after the current sprint or milestone, but sooner than the estimated time for impact. If it’s something that the Project Manager can decide it’s a simple action followed by notifications to both Engineer and Stakeholder. If someone else needs to confirm or approve the decision, then a conversation needs to take place where all the facts gathered and conclusion reached can be quickly reviewed for getting that person onboard. Problem solved.


    Keeping a balance between delivering results and motivating the team generates long-term benefits, offering predictability for the work performed while keeping team members happy and the accumulated business knowledge remains there on the team. This can be achieved by the decision maker – in our case the Project Manager – understanding each situation that appears, discussing with all the parties involved to know all the facts, acting immediately and moving on to the next item on the agenda.